ପାରଦର୍ଶୀ ପ୍ରକ୍ସି DNAT: ଫେରନ୍ତା ପଥ କାହିଁକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ

ଏକ ରିଡାଇରେକ୍ଟ ହୋଇଥିବା SYN Squid ପର୍ଯ୍ୟନ୍ତ ପହଞ୍ଚିପାରେ, ମାତ୍ର ଗ୍ରାହକ ଏବେ ମଧ୍ୟ ସମୟ ସୀମା ପାଉଛନ୍ତି। DNAT ସେଟଅପରେ ଫେରନ୍ତା ପ୍ୟାକେଟ ମଧ୍ୟ ଅନୁବାଦ ସ୍ଥିତି ଥିବା ଗେଟୱେ ପର୍ଯ୍ୟନ୍ତ ପହଞ୍ଚିବା ଆବଶ୍ୟକ।

ଏହି କାଳ୍ପନିକ LAN କୁ ବିଚାର କରନ୍ତୁ:

client 192.168.40.25 → gateway 192.168.40.1
                         DNAT → proxy 192.168.40.10
proxy 192.168.40.10 → client 192.168.40.25 directly

ଗ୍ରାହକ ପ୍ରଥମେ ଏକ ୱେବସାଇଟ ଠିକଣାରେ ସଂଯୁକ୍ତ ହୋଇଥିଲେ। DNAT ପରେ ପ୍ରକ୍ସି ଗ୍ରାହକର ଉତ୍ସ ଦେଖେ ଏବଂ ସ୍ଥାନୀୟ ସବନେଟ ପଥ ବ୍ୟବହାର କରି ସିଧାସଳଖ ଉତ୍ତର ଦେଇପାରେ। ସେହି ଉତ୍ତର ଗେଟୱେର ଓଲଟା ଅନୁବାଦ ଛାଡ଼ିଯାଏ ଏବଂ ଆଶା କରାଯାଉଥିବା ୱେବସାଇଟ ଠିକଣା ପରିବର୍ତ୍ତେ ପ୍ରକ୍ସି ଠିକଣାରୁ ଗ୍ରାହକ ପର୍ଯ୍ୟନ୍ତ ପହଞ୍ଚିପାରେ। ଗେଟୱେ ଯେଉଁ ପ୍ୟାକେଟ କେବେ ପାଏ ନାହିଁ ତାହା ମରାମତି କରିପାରିବ ନାହିଁ।

ସୁନ୍ଦର ଲଗ ପାଇଁ ଫେରନ୍ତା ପଥ ଯାଞ୍ଚ ନକରି SNAT ହଟାନ୍ତୁ ନାହିଁ। ଏହାକୁ ବ୍ୟାପକ ଭାବରେ ଲାଗୁ କଲେ ଉତ୍ସ ACL ଓ ଆଟ୍ରିବ୍ୟୁସନ ମଧ୍ୟ ବଦଳେ; ସେହି ଫଳାଫଳକୁ ଡିଜାଇନର ଅଂଶ ଭାବରେ ଗ୍ରହଣ କରନ୍ତୁ।

ଏକ ବିଶ୍ୱସ୍ତ HTTP ହପ ଫରୱାର୍ଡିଂ ହେଡରରେ ଗ୍ରାହକ ମେଟାଡାଟା ପଠାଇପାରେ, କିନ୍ତୁ NAT ସେହି ହେଡର ସୃଷ୍ଟି କରେ ନାହିଁ କିମ୍ବା ଏହାକୁ TCP ସାଥୀ ପରିଚୟରେ ପରିଣତ କରେ ନାହିଁ। Squid ପର୍ଯ୍ୟନ୍ତ ସଂଯୋଗରେ ଉତ୍ସ ରଖିବା ଏହାକୁ Squid ର ଅଲଗା ୱେବସାଇଟ ସଂଯୋଗରେ ମଧ୍ୟ ରଖେ ନାହିଁ।

ଶେଷରେ, ଇଣ୍ଟରସେପ୍ସନ ଡିଜାଇନକୁ ଏବେ ମଧ୍ୟ Squid ଆବଶ୍ୟକ କରୁଥିବା ଗନ୍ତବ୍ୟ ସୂଚନା ଦେବାକୁ ପଡ଼ିବ। ସମମିତ ଫେରନ୍ତା ରାଉଟିଂ ଏହି ସମୟ ସୀମା ଯନ୍ତ୍ରକୁ ସମାଧାନ କରେ, ସମଗ୍ର ପାରଦର୍ଶୀ-ପ୍ରକ୍ସି ବିନ୍ୟାସକୁ ନୁହେଁ।