Squid ମାଧ୍ୟମରେ ଆଉ ଗୋଟିଏ HTTPS ପୋର୍ଟକୁ ଅନୁମତି ଦିଅନ୍ତୁ

443ରେ ସାଧାରଣ HTTPS କାମ କରୁଥିଲେ ମଧ୍ୟ ପୋର୍ଟ 8443ର HTTPS ସେବା ସଠିକ୍ ଭାବେ ବିନ୍ୟାସ କରାଯାଇଥିବା Squid ପ୍ରକ୍ସି ମାଧ୍ୟମରେ ବିଫଳ ହୋଇପାରେ। କ୍ଲାଏଣ୍ଟର ପ୍ରକ୍ସି ପ୍ରୋଟୋକଲ ବଦଳାଇବା ପୂର୍ବରୁ CONNECT ପ୍ରତ୍ୟାଖ୍ୟାନ ଏବଂ ଗନ୍ତବ୍ୟ ପୋର୍ଟ ନୀତି ଯାଞ୍ଚ କରନ୍ତୁ।

Squid 6.13ର ସାଧାରଣ ପ୍ରବେଶ ନୀତିରେ ଦୁଇଟି ଯାଞ୍ଚ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ: ଗନ୍ତବ୍ୟକୁ Safe_ports ଏବଂ CONNECTକୁ SSL_ports ଯାଞ୍ଚ ପାର କରିବାକୁ ହେବ। କେବଳ ଗୋଟିଏ ACLରେ ପୋର୍ଟ ଯୋଡ଼ିଲେ ଅନ୍ୟ ପ୍ରତ୍ୟାଖ୍ୟାନ ଲାଗୁ ରହିପାରେ।

ବର୍ତ୍ତମାନର ସଂଜ୍ଞାଗୁଡ଼ିକୁ ଭାବିଚିନ୍ତି ବିସ୍ତାର କରନ୍ତୁ

ସାଧାରଣ ୱେବ୍ ପୋର୍ଟ ଏବଂ ଆଉ ଗୋଟିଏ HTTPS ପୋର୍ଟକୁ ଅନୁମତି ଦେଉଥିବା ନୀତି ପାଇଁ:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

ପୁରୁଣା ମୂଲ୍ୟର ଅପ୍ରତ୍ୟାଶିତ ସମୂହ ରହି ନ ଯାଉ ବୋଲି ସମ୍ପୃକ୍ତ ସଂଜ୍ଞାଗୁଡ଼ିକୁ ବଦଳାନ୍ତୁ କିମ୍ବା ସମ୍ପାଦନ କରନ୍ତୁ। ଅସୁରକ୍ଷିତ ପୋର୍ଟ ଏବଂ CONNECT ପ୍ରତ୍ୟାଖ୍ୟାନର ସାଧାରଣ ନିୟମ ସହିତ ଉଦ୍ଦିଷ୍ଟ କ୍ଲାଏଣ୍ଟ ପ୍ରତିବନ୍ଧକଗୁଡ଼ିକ ରଖନ୍ତୁ।

ବ୍ୟତିକ୍ରମକୁ ସୀମିତ ରଖନ୍ତୁ

ଅତିରିକ୍ତ ପୋର୍ଟ କେବଳ ଗୋଟିଏ ନିୟନ୍ତ୍ରିତ ଗନ୍ତବ୍ୟ ପାଇଁ ଦରକାର ହେଲେ କ୍ଲାଏଣ୍ଟ ଅନୁମତି ନିୟମ ପୂର୍ବରୁ ନିର୍ଦ୍ଦିଷ୍ଟ ପ୍ରତ୍ୟାଖ୍ୟାନ ଯୋଡ଼ନ୍ତୁ:

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

ଏହି ଠିକଣା ଦଲିଲ ପାଇଁ ଏକ ଉଦାହରଣ। ଆପଣ ପରିଚାଳନା କରୁଥିବା କିମ୍ବା ପ୍ରବେଶ ପାଇଁ ଅନୁମତି ଥିବା ଗନ୍ତବ୍ୟ ବ୍ୟବହାର କରନ୍ତୁ ଏବଂ ତାହାର ଠିକଣାର ବାସ୍ତବ ପରିବର୍ତ୍ତନ ବିଚାର କରନ୍ତୁ। ଏହା 8443ରେ ସବୁ ଗନ୍ତବ୍ୟକୁ ଅନୁମତି ଦେବା ପରିବର୍ତ୍ତେ ଅତିରିକ୍ତ ପୋର୍ଟର ବ୍ୟତିକ୍ରମକୁ ସୀମିତ କରେ।

ସମ୍ପୂର୍ଣ୍ଣ ସକ୍ରିୟ ବିନ୍ୟାସ ପାର୍ସ କରନ୍ତୁ ଏବଂ ନିୟମର କ୍ରମ ଯାଞ୍ଚ କରନ୍ତୁ। ସଠିକ୍ ଲେଖାଯାଇଥିବା ପ୍ରତ୍ୟାଖ୍ୟାନ ମଧ୍ୟ ଉଦ୍ଦିଷ୍ଟ ପ୍ରତିବନ୍ଧକ ଦେବ ନାହିଁ ଯଦି ତାହା ମେଳ ଖାଉଥିବା କ୍ଲାଏଣ୍ଟ ଅନୁମତି ନିୟମ ପରେ ରଖାଯାଏ।

ଅନୁମୋଦିତ ହୋଷ୍ଟନାମକୁ ତାହାର ପ୍ରକୃତ ସାର୍ଟିଫିକେଟ ଏବଂ ପୋର୍ଟ ସହିତ ପରୀକ୍ଷା କରନ୍ତୁ, ତାପରେ ଏମିତି ନିୟନ୍ତ୍ରିତ ଗନ୍ତବ୍ୟ ପରୀକ୍ଷା କରନ୍ତୁ ଯାହା ଏବେ ମଧ୍ୟ ପ୍ରତ୍ୟାଖ୍ୟାତ ରହିବା ଉଚିତ। ଗନ୍ତବ୍ୟ ପରିଚୟ ତ୍ରୁଟି ଏବଂ ପ୍ରକ୍ସି ନୀତି ତ୍ରୁଟି ଅଲଗା କରିବାକୁ TLS ଯାଞ୍ଚ ଚାଲୁ ରଖନ୍ତୁ। କଷ୍ଟମ ପୋର୍ଟରେ ଗୋଟିଏ ଅନୁରୋଧ ଚଳାଇବାକୁ ସମ୍ପୂର୍ଣ୍ଣ CONNECT ସୁରକ୍ଷା ହଟାନ୍ତୁ ନାହିଁ।