Az Apache AllowCONNECT és a HTTPS célportok

Az Apache proxyja a 3128-as porton figyel. Egy ügyfél sikeresen eléri, de a 8443-as porton futó HTTPS-szolgáltatás meghiúsul. A proxy figyelőportjának módosítása valószínűleg nem kezeli ezt a konkrét különbséget.

Az ügyfél először a proxy figyelőjéhez kapcsolódik. A CONNECT kérés ezután külön célgazdát és célportot nevez meg. Az Apache elfogadhatja az első kapcsolatot, és elutasíthatja a második műveletet.

Az AllowCONNECT célirányelveként olvasandó

Az Apache 2.4 esetében a mod_proxy_connect kezeli a bejövő CONNECT kéréseket. A AllowCONNECT direktívája szabályozza az e kérésekhez elérhető célportokat. A dokumentált alapértelmezés a 443 és az 563.

AllowCONNECT 443 8443

Ez a példa azt a két célportot választja ki. Lecseréli az alapértelmezett kiválasztást; nem adja hozzá a 8443-at, miközben csendben megtartaná az összes alapértelmezett portot. Használja a direktívát az érintett kiszolgáló- vagy virtuálisgazda-konfigurációban.

Tartsa meg a proxy ügyfél-jogosultsági szabályait. Az engedélyezett célport semmit sem mond arról, melyik ügyfél használhatja a szolgáltatást, és nem helyettesíti a célgazda-korlátozást, amikor arra szükség van.

A fordított proxy példája más kérdésre válaszol

Az Apache és a HTTPS keresési találatai gyakran egy nyilvános webhelyet mutatnak, amely egy rögzített háttérrendszerre továbbít. Ez a konfiguráció nem az, ahogyan egy böngésző egy előre irányuló proxytól CONNECT-alagút megnyitását kéri egy kiválasztott webhelyhez. Az útválasztási direktíváinak másolása érintetlenül hagyhatja az eredeti proxyproblémát.

Hiba diagnosztizálásakor jegyezze fel a figyelőt, amelyet az ügyfél elért, a kért CONNECT-hatóságot és a proxy válaszát. Ha a CONNECT sikeres, és utána a TLS meghiúsul, a célport-engedély már megtette a maga részét. Folytassa a TLS-hibával ahelyett, hogy újra meg újra szélesítené az AllowCONNECT-et.