3proxy ର HTTP ଓ SOCKS ଉଭୟ ସେବାରେ ଲଗଇନ ଆବଶ୍ୟକ କରନ୍ତୁ

ଜଣେ ବ୍ୟବହାରକାରୀ ନିର୍ଦ୍ଧାରଣ କରିବା 3proxy ର ସମ୍ପୂର୍ଣ୍ଣ ଲଗଇନ ବିନ୍ୟାସ ନୁହେଁ। ସେବାକୁ ଏକ ପ୍ରମାଣୀକରଣ ପଦ୍ଧତି ଓ ତାହାକୁ ବ୍ୟବହାର କରୁଥିବା ପ୍ରବେଶ ନିୟମ ମଧ୍ୟ ଆବଶ୍ୟକ। କ୍ରମ ମହତ୍ତ୍ୱପୂର୍ଣ୍ଣ କାରଣ ବିନ୍ୟାସ ପ୍ରକ୍ରିୟା ସମୟରେ ସେବା ସେଟିଂ ଲାଗୁ ହୁଏ।

ଦୁଇଟି ସେବା ପାଇଁ କେବଳ ସ୍ଥାନୀୟ ଉଦାହରଣ:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

ବିନ୍ୟାସ ସନ୍ଦର୍ଭ users, auth strong ଓ ସେବା ନିର୍ଦ୍ଦେଶ ବ୍ୟାଖ୍ୟା କରେ। CL ଏହି ଉଦାହରଣ ପାସୱାର୍ଡକୁ ସାଧାରଣ ପାଠ୍ୟ ଭାବରେ ସଂରକ୍ଷଣ କରେ। ଫାଇଲକୁ ସୁରକ୍ଷିତ ରଖନ୍ତୁ ଓ ନିୟୋଜନ ପାଇଁ ଉପଯୁକ୍ତ ସମର୍ଥିତ ପ୍ରମାଣପତ୍ର ସଂରକ୍ଷଣ ରୂପ ବାଛନ୍ତୁ।

କ୍ଲାଏଣ୍ଟକୁ ସଠିକ ଲଗଇନ ବିନିମୟ ଆବଶ୍ୟକ

HTTP ସେବା HTTP ପ୍ରକ୍ସି ପ୍ରମାଣୀକରଣ ଆଶା କରେ। SOCKS ସେବାକୁ SOCKS5 ବ୍ୟବହାରକାରୀ ନାମ ଓ ପାସୱାର୍ଡ ପ୍ରମାଣୀକରଣ ସମର୍ଥନ କରୁଥିବା କ୍ଲାଏଣ୍ଟ ଆବଶ୍ୟକ। SOCKS4 କ୍ଲାଏଣ୍ଟ କେବଳ ସେହି ଶ୍ରବଣ ପୋର୍ଟରେ ପହଞ୍ଚୁଥିବା ହେତୁ ସେହି ବିନିମୟ ଦେଇପାରିବ ନାହିଁ।

strong ଶବ୍ଦଟି ପ୍ରମାଣୀକରଣ ମୋଡର ନାମ, ଏନକ୍ରିପ୍ଟେଡ ପରିବହନର ନିଶ୍ଚିତତା ନୁହେଁ। ଆବଶ୍ୟକ ହେଲେ କ୍ଲାଏଣ୍ଟରୁ ପ୍ରକ୍ସି ପର୍ଯ୍ୟନ୍ତ ଅଂଶ ସୁରକ୍ଷିତ ରଖନ୍ତୁ। ଲକ୍ଷ୍ୟସ୍ଥାନକୁ HTTPS ଓ ପ୍ରକ୍ସିକୁ ଏନକ୍ରିପ୍ସନ ଅଲଗା ନିଷ୍ପତ୍ତି ହୋଇ ରହେ।

ଲୁପବ୍ୟାକ ବାଇଣ୍ଡିଂ ଏହି ଉଦାହରଣକୁ ସ୍ଥାନୀୟ ପ୍ରବେଶରେ ସୀମିତ କରେ। ଦୂର କ୍ଲାଏଣ୍ଟ ପାଇଁ ଉଦ୍ଦିଷ୍ଟ ଶ୍ରୋତା ଓ ନେଟୱାର୍କ ନୀତି ସ୍ପଷ୍ଟ ଭାବରେ ବାଛନ୍ତୁ। ସାର୍ବଜନୀନ ୱାଇଲ୍ଡକାର୍ଡ ଶ୍ରୋତା ଲଗଇନ ଆଚରଣ ଯାଞ୍ଚ କରିବାର ବିକଳ୍ପ ନୁହେଁ।

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