Apache AllowCONNECT ja HTTPS-i sihtpordid
Eristage porti, millega kliendid Apache'i puhverserverini jõuavad, sihtportidest, mida mod_proxy_connect tunnelites lubab.
Teie Apache'i puhverserver kuulab porti 3128. Klient jõuab selleni edukalt, kuid HTTPS-teenus pordil 8443 ei tööta. Puhverserveri kuulamisporti muutmine tõenäoliselt seda erinevust ei lahenda.
Klient loob esmalt ühenduse puhverserveri kuulajaga. Seejärel nimetab selle CONNECT-päring eraldi sihtkoha hosti ja pordi. Apache võib esimese ühenduse vastu võtta ja teise toimingu tagasi lükata.
Käsitlege AllowCONNECTi sihtpoliitikana
Apache 2.4 puhul käsitleb mod_proxy_connect sissetulevaid CONNECT-päringuid. Selle AllowCONNECT direktiiv juhib nende päringute jaoks saadaolevaid sihtporte. Dokumenteeritud vaikeväärtus on 443 ja 563.
AllowCONNECT 443 8443See näide valib need kaks sihtporti. See asendab vaikevaliku; see ei lisa 8443, säilitades samal ajal vaikselt kõiki vaikeporte. Kasutage direktiivi vastavas serveri või virtuaalhosti konfiguratsioonis.
Hoidke puhverserveri kliendi autoriseerimisreeglid paigas. Lubatud sihtport ei ütle midagi selle kohta, milline klient võib teenust kasutada, ega asenda sihtkoha hosti piirangut, kui seda on vaja.
Pöördpuhverserveri näide vastab teisele küsimusele
Apache'i ja HTTPS-i otsingutulemused näitavad sageli avalikku veebisaiti, mis suunab fikseeritud taustarakendusele. See konfiguratsioon ei ole see, kuidas brauser palub edasipürgival puhverserveril avada valitud veebisaidile CONNECT-tunnel. Selle marsruutimisdirektiivide kopeerimine võib algse puhverserveri probleemi puutumata jätta.
Tõrke diagnoosimisel registreerige kuulaja, kelleni klient jõudis, taotletud CONNECT-i autoriteet ja puhverserveri vastus. Kui CONNECT õnnestub ja TLS nurjub seejärel, on sihtpordi luba oma osa juba teinud. Jätkake TLS-i tõrkega, mitte AllowCONNECTi korduva laiendamisega.