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 பற்றிய தேடல் முடிவுகள் பெரும்பாலும் ஒரு பொது இணையதளம் நிலையான பின்தளத்திற்கு அனுப்புவதைக் காட்டுகின்றன. அந்த உள்ளமைவு, தேர்ந்தெடுக்கப்பட்ட இணையதளத்திற்கு CONNECT சுரங்கப்பாதையைத் திறக்க முன்னோக்கு ப்ராக்ஸியை உலாவி கேட்கும் விதம் அல்ல. அதன் வழிசெலுத்தல் கட்டளைகளை நகலெடுத்தால் அசல் ப்ராக்ஸி சிக்கல் தொடாமல் இருக்கலாம்.

தோல்வியைக் கண்டறியும்போது, வாடிக்கையாளர் அடைந்த கேட்பான், கோரிய CONNECT அதிகாரம், ப்ராக்ஸியின் பதில் ஆகியவற்றைப் பதிவு செய்யுங்கள். CONNECT வெற்றியடைந்து பின்னர் TLS தோல்வியடைந்தால், இலக்கு துறை அனுமதி தன் பங்கைச் செய்துவிட்டது. தொடர்ந்து TLS தோல்வியைக் கவனியுங்கள்; AllowCONNECT ஐ மீண்டும் மீண்டும் விரிவுபடுத்த வேண்டாம்.