Apache AllowCONNECT ଏବଂ HTTPS ଲକ୍ଷ୍ୟ ପୋର୍ଟ

ଆପଣଙ୍କ Apache ପ୍ରକ୍ସି 3128 ପୋର୍ଟରେ ଶୁଣୁଛି। ଏକ କ୍ଲାଏଣ୍ଟ ସଫଳତାର ସହ ଏଥିରେ ପହଞ୍ଚେ, କିନ୍ତୁ 8443 ପୋର୍ଟରେ ଥିବା HTTPS ସେବା ବିଫଳ ହୁଏ। ପ୍ରକ୍ସିର ଶୁଣିବା ପୋର୍ଟ ବଦଳାଇବା ସେହି ପାର୍ଥକ୍ୟକୁ ସମାଧାନ କରିବାର ସମ୍ଭାବନା କମ୍।

କ୍ଲାଏଣ୍ଟ ପ୍ରଥମେ ପ୍ରକ୍ସି ଲିସନର ସହିତ ସଂଯୋଗ ହୁଏ। ତା’ପରେ ଏହାର CONNECT ଅନୁରୋଧ ଏକ ପୃଥକ ଲକ୍ଷ୍ୟ ହୋଷ୍ଟ ଏବଂ ପୋର୍ଟ ନାମ ଦିଏ। Apache ପ୍ରଥମ ସଂଯୋଗକୁ ଗ୍ରହଣ କରିପାରେ ଏବଂ ଦ୍ୱିତୀୟ କାର୍ଯ୍ୟକୁ ପ୍ରତ୍ୟାଖ୍ୟାନ କରିପାରେ।

AllowCONNECT କୁ ଲକ୍ଷ୍ୟ ନୀତି ଭାବରେ ପଢ଼ନ୍ତୁ

Apache 2.4 ପାଇଁ, mod_proxy_connect ଆସୁଥିବା CONNECT ଅନୁରୋଧଗୁଡ଼ିକୁ ପରିଚାଳନା କରେ। ଏହାର AllowCONNECT ନିର୍ଦ୍ଦେଶ ସେହି ଅନୁରୋଧଗୁଡ଼ିକ ପାଇଁ ଉପଲବ୍ଧ ଲକ୍ଷ୍ୟ ପୋର୍ଟଗୁଡ଼ିକୁ ନିୟନ୍ତ୍ରଣ କରେ। ଡକ୍ୟୁମେଣ୍ଟେଡ୍ ଡିଫଲ୍ଟ ହେଉଛି 443 ଏବଂ 563।

AllowCONNECT 443 8443

ଏହି ଉଦାହରଣ ସେହି ଦୁଇଟି ଲକ୍ଷ୍ୟ ପୋର୍ଟ ବାଛେ। ଏହା ଡିଫଲ୍ଟ ଚୟନକୁ ବଦଳାଏ; ସମସ୍ତ ଡିଫଲ୍ଟ ପୋର୍ଟ ଚୁପଚାପ୍ ରଖି 8443 ଯୋଡ଼େ ନାହିଁ। ଲାଗୁ ହେଉଥିବା ସର୍ଭର କିମ୍ବା ଭର୍ଚୁଆଲ୍ ହୋଷ୍ଟ କନଫିଗରେସନରେ ନିର୍ଦ୍ଦେଶ ବ୍ୟବହାର କରନ୍ତୁ।

ପ୍ରକ୍ସିର କ୍ଲାଏଣ୍ଟ ଅନୁମତି ନିୟମ ଯଥାସ୍ଥାନରେ ରଖନ୍ତୁ। ଅନୁମତିପ୍ରାପ୍ତ ଲକ୍ଷ୍ୟ ପୋର୍ଟ କେଉଁ କ୍ଲାଏଣ୍ଟ ସେବା ବ୍ୟବହାର କରିପାରିବ ତାହା କିଛି କହେ ନାହିଁ, ଏବଂ ଆବଶ୍ୟକ ହେଲେ ଏହା ଲକ୍ଷ୍ୟ-ହୋଷ୍ଟ ପ୍ରତିବନ୍ଧକର ବିକଳ୍ପ ନୁହେଁ।

ଏକ ରିଭର୍ସ-ପ୍ରକ୍ସି ଉଦାହରଣ ଅନ୍ୟ ପ୍ରଶ୍ନର ଉତ୍ତର ଦିଏ

Apache ଏବଂ HTTPS ପାଇଁ ସନ୍ଧାନ ଫଳାଫଳ ପ୍ରାୟତଃ ଏକ ସାର୍ବଜନୀନ ୱେବସାଇଟ୍ ଦେଖାଏ ଯାହା ସ୍ଥିର backend କୁ ଫରୱାର୍ଡ କରେ। ସେ କନଫିଗରେସନ୍ ବ୍ରାଉଜର ଏକ ଫରୱାର୍ଡ ପ୍ରକ୍ସିକୁ ଚୟନିତ ୱେବସାଇଟ୍ ପାଇଁ CONNECT ଟନେଲ ଖୋଲିବାକୁ କହିବାର ଉପାୟ ନୁହେଁ। ଏହାର ରାଉଟିଂ ନିର୍ଦ୍ଦେଶକୁ କପି କଲେ ମୂଳ ପ୍ରକ୍ସି ସମସ୍ୟା ଅସ୍ପୃଷ୍ଟ ରହିପାରେ।

ବିଫଳତା ନିର୍ଣ୍ଣୟ କରିବାବେଳେ, କ୍ଲାଏଣ୍ଟ ପହଞ୍ଚିଥିବା ଲିସନର, ମାଗିଥିବା CONNECT ଅଧିକାର ଏବଂ ପ୍ରକ୍ସିର ଉତ୍ତର ଲିପିବଦ୍ଧ କରନ୍ତୁ। ଯଦି CONNECT ସଫଳ ହୁଏ ଏବଂ ପରେ TLS ବିଫଳ ହୁଏ, ଲକ୍ଷ୍ୟ-ପୋର୍ଟ ଅନୁମତି ନିଜ ଅଂଶ ପୂର୍ବରୁ ସମ୍ପନ୍ନ କରିଛି। AllowCONNECT କୁ ବାରମ୍ବାର ବିସ୍ତାର ନକରି TLS ବିଫଳତା ସହିତ ଆଗେଇ ଯାଆନ୍ତୁ।