Squid IPv4 କ୍ଲାଏଣ୍ଟ ଏବଂ IPv6 ଗନ୍ତବ୍ୟ: ପୃଥକ ନୀତି

IPv4 ମାଧ୍ୟମରେ କ୍ଲାଏଣ୍ଟ ଗ୍ରହଣ କରି ତାହାର ଅନୁରୋଧିତ ୱେବସାଇଟକୁ IPv6 ମାଧ୍ୟମରେ ପହଞ୍ଚିବା ସମ୍ଭବ। ଏହି ଗୁଡ଼ିକ ପୃଥକ ସଂଯୋଗ। ୱେବସାଇଟ ପାର୍ଶ୍ୱର ନୀତି IPv4 କ୍ଲାଏଣ୍ଟମାନଙ୍କୁ ସ୍ୱଚାଳିତ ଭାବେ ପ୍ରତ୍ୟାଖ୍ୟାନ କରିବା ଉଚିତ ନୁହେଁ।

src ipv4 ସହିତ ଗନ୍ତବ୍ୟ-ପରିବାର ନିଷେଧକୁ ଯୋଡ଼ୁଥିବା ଉଦାହରଣରେ ଏହା ହିଁ ଫାନ୍ଦ: ଉତ୍ସ ACL ପରିବର୍ତ୍ତନ କରେ କିଏ ସଂଯୋଗ କରିପାରିବ, କେବଳ କେଉଁ ୱେବସାଇଟ ସଂଯୋଗ ଅନୁମତିପ୍ରାପ୍ତ ତାହା ନୁହେଁ।

ଉଦ୍ଦିଷ୍ଟ ପ୍ରତିବନ୍ଧକ ପରିଭାଷିତ କରନ୍ତୁ

ପ୍ରାସଙ୍ଗିକ IP ACL ସମର୍ଥନ କରୁଥିବା Squid ସଂସ୍କରଣ ପାଇଁ, ଗନ୍ତବ୍ୟ-ପରିବାର ନିୟମ IPv4 ଗନ୍ତବ୍ୟ ଚିହ୍ନଟ କରିବାକୁ dst ipv4 ବ୍ୟବହାର କରିପାରେ। ଏପରି ନିୟମକୁ ବିଦ୍ୟମାନ ପ୍ରମାଣୀକରଣ ଏବଂ ଗନ୍ତବ୍ୟ ଅନୁମତି ସହିତ ସଂଯୋଜିତ କରନ୍ତୁ; ସେଗୁଡ଼ିକୁ ବାଇପାସ କରୁଥିବା ବ୍ୟାପକ IPv6 ଅନୁମତି ଯୋଡ଼ନ୍ତୁ ନାହିଁ।

ACL ସନ୍ଦର୍ଭ ଉତ୍ସ ଏବଂ ଗନ୍ତବ୍ୟ ପ୍ରକାରକୁ ପୃଥକ କରେ। ଏହା ଏକ ପ୍ରତିବନ୍ଧକ, ସ୍ୱଚାଳିତ ଅନୁବାଦ ସେବା ନୁହେଁ। କେବଳ-IPv4 ୱେବସାଇଟ ଅନୁପଲବ୍ଧ ହୋଇପାରେ, ଯଦିଓ ମେସିନ IPv4 ମାଧ୍ୟମରେ ଏହାକୁ ପହଞ୍ଚିପାରିଥାନ୍ତା।

ବହିର୍ଗାମୀ IPv6 ଠିକଣା ବାନ୍ଧିବା ମଧ୍ୟ ସମ୍ପୂର୍ଣ୍ଣ ପ୍ରବର୍ତ୍ତନ ନୀତି ନୁହେଁ। ଉତ୍ସ ଚୟନ, ଅନୁମତିପ୍ରାପ୍ତ ଗନ୍ତବ୍ୟ ପରିବାର, DNS ଉତ୍ତର ଏବଂ ପ୍ରକୃତ ନେଟୱର୍କ ପ୍ରାପ୍ୟତା ସମସ୍ତେ ଯୋଗଦାନ କରନ୍ତି। IPv4 ଫଲବ୍ୟାକ ଗ୍ରହଣୀୟ କି ନୁହେଁ ସ୍ପଷ୍ଟ ଭାବେ ସ୍ଥିର କରନ୍ତୁ।

forwarded_for ପରିବର୍ତ୍ତନ କଲେ ଏହି ସମସ୍ୟା ସମାଧାନ ହୁଏ ନାହିଁ। ଏହା HTTP ହେଡରକୁ ପ୍ରଭାବିତ କରେ, ପ୍ରକ୍ସିର TCP ସଂଯୋଗର ଠିକଣା ପରିବାରକୁ ନୁହେଁ। ସେହିପରି, IPv6 DNS ରିଜୋଲଭର ଏହା ନିଶ୍ଚିତ କରେ ନାହିଁ ଯେ ଏହା ଉତ୍ତର ଦେଉଥିବା ପ୍ରତ୍ୟେକ ନାମର IPv6 ଗନ୍ତବ୍ୟ ଅଛି।

ବଡ଼ ପୁରୁଣା ବିନ୍ୟାସ ଗ୍ରହଣ କରିବା ପୂର୍ବରୁ ସଂସ୍କରଣ-ନିର୍ଦ୍ଦିଷ୍ଟ ଆଚରଣ ଯାଞ୍ଚ କରନ୍ତୁ। ବିଶେଷକରି: dns_v4_first Squid 5 ରୁ 7 ପର୍ଯ୍ୟନ୍ତ ସମର୍ଥିତ ପରିବାର-ପ୍ରାଥମିକତା ସୁଇଚ ନୁହେଁ। ଆପଣ ସଠିକ୍ ଭାବେ ବର୍ଣ୍ଣନା କରିପାରିବା ଏକ ନୀତି ଅସମ୍ବନ୍ଧିତ IPv6 ସେଟିଂର ସଂଗ୍ରହଠାରୁ ସହଜରେ ବୈଧ ହୋଇପାରେ।