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 പരാജയപ്പെട്ടാൽ, ലക്ഷ്യ-പോർട്ട് അനുമതി അതിന്റെ ഭാഗം ഇതിനകം ചെയ്തിട്ടുണ്ട്. AllowCONNECT ആവർത്തിച്ച് വിശാലമാക്കുന്നതിനുപകരം TLS പരാജയം കൈകാര്യം ചെയ്യുക.