Apache AllowCONNECT og HTTPS-destinasjonsportar

Apache-proxyen din lyttar på port 3128. Ein klient når han, men ein HTTPS-teneste på port 8443 feilar. Å endre den lyttande porten til proxyen løyser neppe nettopp denne skilnaden.

Klienten koplar først til lyttaren til proxyen. CONNECT-førespurnaden hans namngjev deretter ein eigen destinasjonsvert og -port. Apache kan godta den første tilkoplinga og avvise den andre operasjonen.

Les AllowCONNECT som ein destinasjonspolicy

For Apache 2.4 handterer mod_proxy_connect innkomande CONNECT-førespurnader. Direktivet AllowCONNECT styrer destinasjonsportane som er tilgjengelege for desse førespurnadene. Standardverdien i dokumentasjonen er 443 og 563.

AllowCONNECT 443 8443

Dette dømet vel desse to destinasjonsportane. Det erstattar standardutvalet; det legg ikkje til 8443 medan alle standardportar blir haldne stille att. Bruk direktivet i den aktuelle server- eller virtual host-konfigurasjonen.

Hald klientautorisasjonsreglane til proxyen på plass. Ein tillaten destinasjonsport seier ingenting om kva klient som kan bruke tenesta, og han erstattar ikkje ei avgrensing av destinasjonsverten når ei slik er nødvendig.

Eit omvendt proxy-døme svarer på eit anna spørsmål

Søkjeresultat for Apache og HTTPS viser ofte eit offentleg nettstad som vidaresender til ein fast backend. Den konfigurasjonen er ikkje måten ein nettlesar ber ein videresendingsproxy opne ein CONNECT-tunnel til ein vald nettstad. Å kopiere rutingsdirektiva kan la det opphavlege proxyproblemet stå urørt.

Når du diagnostiserer ein feil, noter lyttaren klienten nådde, CONNECT-autoriteten han bad om, og svaret frå proxyen. Viss CONNECT lukkast og TLS feilar etterpå, har destinasjonsportløyvet alt gjort sin del. Hald fram med TLS-feilen i staden for å utvide AllowCONNECT om og om att.