Apache AllowCONNECT og HTTPS-destinasjonsporter

Apache-proxyen din lytter på port 3128. En klient når den, men en HTTPS-tjeneste på port 8443 feiler. Å endre proxyens lyttende port vil neppe løse akkurat denne forskjellen.

Klienten kobler først til proxyens lytter. Dens CONNECT-forespørsel navngir deretter en egen destinasjonsvert og -port. Apache kan godta den første forbindelsen og avvise den andre operasjonen.

Les AllowCONNECT som en destinasjonspolicy

For Apache 2.4 håndterer mod_proxy_connect innkommende CONNECT-forespørsler. Direktivet AllowCONNECT styrer destinasjonsportene som er tilgjengelige for disse forespørslene. Standardverdien i dokumentasjonen er 443 og 563.

AllowCONNECT 443 8443

Dette eksempelet velger disse to destinasjonsportene. Det erstatter standardutvalget; det legger ikke til 8443 mens alle standardporter beholdes i det stille. Bruk direktivet i den aktuelle server- eller virtual host-konfigurasjonen.

Behold proxyens klientautorisasjonsregler på plass. En tillatt destinasjonsport sier ingenting om hvilken klient som kan bruke tjenesten, og den erstatter ikke en destinasjonsvertbegrensning når en slik er nødvendig.

Et omvendt proxy-eksempel svarer på et annet spørsmål

Søkeresultater for Apache og HTTPS viser ofte et offentlig nettsted som videresender til en fast backend. Den konfigurasjonen er ikke måten en nettleser ber en videresendingsproxy om å åpne en CONNECT-tunnel til et valgt nettsted. Å kopiere rutingdirektivene kan la det opprinnelige proxyproblemet stå urørt.

Når du diagnostiserer en feil, noter lytteren klienten nådde, CONNECT-autoriteten den ba om, og proxyens svar. Hvis CONNECT lykkes og TLS feiler etterpå, har destinasjonsporttillatelsen allerede gjort sin del. Fortsett med TLS-feilen i stedet for å utvide AllowCONNECT gjentatte ganger.