ଏକ ସେବା 127.0.0.1:1080 ରେ ଶୁଣୁଛି। ଏକ DNAT ନିୟମ ଆସୁଥିବା ଟ୍ରାଫିକ୍ କୁ ସେହି ଠିକଣାକୁ ପଠାଏ, ତଥାପି ସଂଯୋଗ ବିଫଳ ହୁଏ। ସେବା ସୁସ୍ଥ ରହିପାରେ ଏବଂ NAT ନିୟମ ମେଳ ଖାଇପାରେ: IPv4 ଲୁପବ୍ୟାକ୍ ଠିକଣାଗୁଡ଼ିକୁ ରାସ୍ତା ନିର୍ଣ୍ଣୟରେ ବିଶେଷ ବ୍ୟବହାର ମିଳେ।

ଲିନକ୍ସର route_localnet ନିର୍ଣ୍ଣୟ କରେ ଯେ ରାସ୍ତା ନିର୍ଣ୍ଣୟ ସମୟରେ 127/8 ଠିକଣାଗୁଡ଼ିକୁ ମଙ୍ଗଳ ଗ୍ରହ ଠିକଣା ଭାବରେ ଗଣନା କରାଯିବ କି ନାହିଁ। ଏହାର ପୂର୍ବନିର୍ଦ୍ଧାରିତ ମୂଲ୍ୟ ସାଧାରଣ ଲୁପବ୍ୟାକ୍ ସୀମା ରକ୍ଷା କରେ। ଏକ ନିର୍ଦ୍ଦିଷ୍ଟ ଇଣ୍ଟରଫେସ୍ ପାଇଁ ବ୍ୟତିକ୍ରମ ଉଦ୍ଦେଶ୍ୟପୂର୍ଣ୍ଣ ସ୍ଥାନୀୟ ପୁନର୍ନିର୍ଦ୍ଦେଶ ଡିଜାଇନ୍ ପାଇଁ ପ୍ରାସଙ୍ଗିକ ହୋଇପାରେ।

ଏହା ବୁଝାଏ ଯେ ଅନ୍ୟ ମେସିନରେ କାମ କରୁଥିବା ନିୟମ ଆପଣ କପି ନକରିଥିବା sysctl ଉପରେ ନିର୍ଭର କରିପାରେ। କିନ୍ତୁ ଏହା ଏହି ବିକଳ୍ପକୁ ସର୍ବତ୍ର ସକ୍ରିୟ କରିବାର ଯଥାର୍ଥତା ଦିଏ ନାହିଁ।

ସୁରକ୍ଷା ଅନୁମାନ ରାସ୍ତା ସହିତ ବଦଳେ

ଲୁପବ୍ୟାକ୍ ବାଇଣ୍ଡିଂ ପ୍ରାୟତଃ ବ୍ୟବହୃତ ହୁଏ କାରଣ ସହାୟକ ଉପାଦାନର ସ୍ୱାଧୀନ ଗ୍ରାହକ ପ୍ରମାଣୀକରଣ ନଥାଏ। ଯଦି ଅନ୍ୟ ଇଣ୍ଟରଫେସ୍ ରୁ ଆସୁଥିବା ଟ୍ରାଫିକ୍ ସେଠାକୁ ରାସ୍ତା ନିର୍ଣ୍ଣୟ ହୋଇପାରେ, ତେବେ କେବଳ ବାଇଣ୍ଡ ଠିକଣା ଆଉ ପହଞ୍ଚିପାରୁଥିବା ଦର୍ଶକଙ୍କୁ ବର୍ଣ୍ଣନା କରେ ନାହିଁ। ପ୍ରକୃତ ନିୟମ ସମୂହରେ ପ୍ରବେଶ ଉତ୍ସ, ଲକ୍ଷ୍ୟ ଏବଂ ପୋର୍ଟ ସୀମିତ କରନ୍ତୁ, ଏବଂ ପ୍ରାସଙ୍ଗିକ ହେଲେ ଲୁପବ୍ୟାକ୍ ଉତ୍ସ କିମ୍ବା ଲକ୍ଷ୍ୟ ଠିକଣା ଦାବି କରୁଥିବା ଟ୍ରାଫିକ୍ ମଧ୍ୟ ଅନ୍ତର୍ଭୁକ୍ତ କରନ୍ତୁ।

ସେବା ଥିବା ନେଟୱାର୍କ ନାମସ୍ଥାନ ସମୀକ୍ଷା କରନ୍ତୁ। କଣ୍ଟେନରର ଲୁପବ୍ୟାକ୍ ହୋଷ୍ଟର ଲୁପବ୍ୟାକ୍ ନୁହେଁ, ଏବଂ ହୋଷ୍ଟ ଇଣ୍ଟରଫେସ୍ ସେଟିଂ ବଦଳାଇବା ଦ୍ୱାରା କଣ୍ଟେନରରେ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଶ୍ରୋତା ସୃଷ୍ଟି ହୁଏ ନାହିଁ।

rp_filter ଉତ୍ସ-ରାସ୍ତା ଯାଞ୍ଚ ବିଷୟରେ ଏକ ଭିନ୍ନ ପ୍ରଶ୍ନର ଉତ୍ତର ଦିଏ। ଏହାକୁ ସର୍ବତ୍ର ବନ୍ଦ କରିବା ଲୁପବ୍ୟାକ୍ ରାସ୍ତା ନିର୍ଣ୍ଣୟ ବୁଝିବାର ସାଧାରଣ ବିକଳ୍ପ ନୁହେଁ। ସେହିପରି ip_nonlocal_bind ସକେଟ୍ ଗୁଡ଼ିକୁ ଅଣ-ସ୍ଥାନୀୟ ଠିକଣାରେ ବାନ୍ଧିବା ବିଷୟରେ, ଏହି DNAT ରାସ୍ତାକୁ ସଠିକ୍ କରିବା ବିଷୟରେ ନୁହେଁ।

ଶେଷରେ, ପୁନର୍ନିର୍ଦ୍ଦେଶିତ ପ୍ରୋଟୋକଲ୍ ଶ୍ରୋତା ସହିତ ମେଳ ଖାଇବା ଆବଶ୍ୟକ। SOCKS ପୋର୍ଟକୁ କଞ୍ଚା HTTP କିମ୍ବା TLS ଟ୍ରାଫିକ୍ ପଠାଇବାକୁ ଏବେ ମଧ୍ୟ ଅନୁବାଦକ ଆବଶ୍ୟକ; ରାସ୍ତା ବ୍ୟତିକ୍ରମ ଅନୁପସ୍ଥିତ ବୁଝାମଣା ଯୋଗାଇ ପାରିବ ନାହିଁ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ