Apache AllowCONNECT ir HTTPS paskirties prievadai

Jūsų Apache tarpinis serveris klausosi prievado 3128. Klientas jį pasiekia sėkmingai, bet HTTPS paslauga prievade 8443 nepavyksta. Tarpinio serverio klausymosi prievado keitimas greičiausiai neišspręs šio konkretaus skirtumo.

Klientas pirmiausia prisijungia prie tarpinio serverio klausytojo. Tada jo CONNECT užklausa nurodo atskirą paskirties mazgą ir prievadą. Apache gali priimti pirmąjį ryšį ir atmesti antrąją operaciją.

Skaitykite AllowCONNECT kaip paskirties politiką

Apache 2.4 atveju mod_proxy_connect apdoroja gaunamas CONNECT užklausas. Jo AllowCONNECT direktyva valdo paskirties prievadus, prieinamus šioms užklausoms. Dokumentuota numatytoji reikšmė yra 443 ir 563.

AllowCONNECT 443 8443

Šis pavyzdys pasirenka tuos du paskirties prievadus. Jis pakeičia numatytąjį pasirinkimą; jis neprideda 8443 ir tyliai neišsaugo visų numatytųjų prievadų. Naudokite direktyvą atitinkamoje serverio ar virtualiojo mazgo konfigūracijoje.

Išlaikykite tarpinio serverio klientų autorizavimo taisykles vietoje. Leidžiamas paskirties prievadas nieko nesako apie tai, kuris klientas gali naudotis paslauga, ir jis nepakeičia paskirties mazgo apribojimo, kai jo reikia.

Atvirkštinio tarpinio serverio pavyzdys atsako į kitą klausimą

Apache ir HTTPS paieškos rezultatai dažnai rodo viešą svetainę, kuri persiunčia į fiksuotą backend. Tokia konfigūracija nėra būdas, kuriuo naršyklė prašo tiesioginio tarpinio serverio atidaryti CONNECT tunelį į pasirinktą svetainę. Jos maršrutizavimo direktyvų kopijavimas gali palikti pradinę tarpinio serverio problemą nepaliestą.

Diagnozuodami gedimą, užrašykite klausytoją, kurį pasiekė klientas, užklaustą CONNECT autoritetą ir tarpinio serverio atsakymą. Jei CONNECT pavyksta, o vėliau TLS nepavyksta, paskirties prievado leidimas jau atliko savo dalį. Tęskite su TLS gedimu užuot vėl ir vėl platinus AllowCONNECT.