Apache AllowCONNECT og HTTPS-destinationsporte

Din Apache-proxy lytter på port 3128. En klient når den, men en HTTPS-tjeneste på port 8443 fejler. Det er usandsynligt, at en ændring af proxyens lyttende port løser netop den forskel.

Klienten forbinder først til proxyens lytter. Dets CONNECT-anmodning angiver derefter en separat destinationsvært og -port. Apache kan acceptere den første forbindelse og afvise den anden handling.

Læs AllowCONNECT som en destinationspolitik

For Apache 2.4 håndterer mod_proxy_connect indgående CONNECT-anmodninger. Dets AllowCONNECT-direktiv styrer de destinationsporte, der er tilgængelige for disse anmodninger. Den dokumenterede standard er 443 og 563.

AllowCONNECT 443 8443

Dette eksempel vælger disse to destinationsporte. Det erstatter standardvalget; det tilføjer ikke 8443, mens alle standardporte stiltiende bevares. Brug direktivet i den relevante server- eller virtuelle vært-konfiguration.

Behold proxyens klientautorisationsregler på plads. En tilladt destinationsport siger intet om, hvilken klient der må bruge tjenesten, og den erstatter ikke en begrænsning af destinationsværten, når en sådan er nødvendig.

Et reverse-proxy-eksempel besvarer et andet spørgsmål

Søgeresultater for Apache og HTTPS viser ofte et offentligt websted, der videresender til et fast backend. Den konfiguration er ikke, hvordan en browser beder en forward-proxy om at åbne en CONNECT-tunnel til et valgt websted. Kopiering af dens routingdirektiver kan efterlade det oprindelige proxyproblem urørt.

Når du diagnosticerer en fejl, skal du registrere den lytter, klienten nåede, den CONNECT-autoritet, den anmodede om, og proxyens svar. Hvis CONNECT lykkes, og TLS derefter fejler, har destinationsporttilladelsen allerede gjort sit. Fortsæt med TLS-fejlen i stedet for gentagne gange at udvide AllowCONNECT.