Apache AllowCONNECT en HTTPS-doelpoorten

Je Apache-proxy luistert op poort 3128. Een client bereikt hem, maar een HTTPS-dienst op poort 8443 mislukt. De luisterende poort van de proxy wijzigen lost dat verschil waarschijnlijk niet op.

De client verbindt eerst met de luisteraar van de proxy. Zijn CONNECT-verzoek noemt daarna een aparte doelhoost en -poort. Apache kan de eerste verbinding accepteren en de tweede bewerking weigeren.

Lees AllowCONNECT als een doelbeleid

Voor Apache 2.4 verwerkt mod_proxy_connect inkomende CONNECT-verzoeken. De richtlijn AllowCONNECT bepaalt welke doelpoorten voor die verzoeken beschikbaar zijn. De gedocumenteerde standaard is 443 en 563.

AllowCONNECT 443 8443

Dit voorbeeld kiest die twee doelpoorten. Het vervangt de standaardselectie; het voegt 8443 niet toe terwijl elke standaardpoort stilzwijgend behouden blijft. Gebruik de richtlijn in de toepasselijke server- of virtualhostconfiguratie.

Houd de clientautorisatieregels van de proxy in stand. Een toegestane doelpoort zegt niets over welke client de dienst mag gebruiken, en is geen vervanging voor een beperking van de doelhoost wanneer die nodig is.

Een reverse-proxyvoorbeeld beantwoordt een andere vraag

Zoekresultaten voor Apache en HTTPS tonen vaak een publieke website die doorstuurt naar een vaste backend. Die configuratie is niet hoe een browser een forward proxy vraagt om een CONNECT-tunnel naar een gekozen website te openen. Het kopiëren van de routeringsrichtlijnen kan het oorspronkelijke proxyprobleem ongemoeid laten.

Noteer bij het diagnosticeren van een storing de luisteraar die de client bereikte, de CONNECT-authority die hij aanvroeg en het antwoord van de proxy. Als CONNECT slaagt en TLS daarna mislukt, heeft de doelpoorttoestemming haar deel al gedaan. Ga verder met de TLS-fout in plaats van AllowCONNECT steeds ruimer te maken.