Tillad én ekstra HTTPS-port gennem Squid

En HTTPS-tjeneste på port 8443 kan fejle gennem en korrekt konfigureret Squid-proxy, selv når almindelig HTTPS på 443 virker. Undersøg CONNECT-afvisningen og politikken for destinationsporte, før du ændrer klientens proxyprotokol.

I en typisk adgangspolitik for Squid 6.13 er to kontroller afgørende: Destinationen skal passere Safe_ports, og CONNECT skal passere SSL_ports. Hvis porten kun føjes til én ACL, kan den anden afvisning fortsat gælde.

Udvid de eksisterende definitioner med omtanke

For en politik, der tillader almindelige webporte og én ekstra HTTPS-port:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Erstat eller rediger de relevante definitioner, så et uventet ældre sæt værdier ikke bliver stående. Bevar de normale regler, der afviser usikre porte og CONNECT, samt de tilsigtede klientbegrænsninger.

Hold undtagelsen snæver

Hvis den ekstra port kun er nødvendig for én kontrolleret destination, skal du tilføje en målrettet afvisning før reglen, der tillader klienten:

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

Adressen er en pladsholder til dokumentation. Brug den destination, du administrerer eller har tilladelse til at tilgå, og tag højde for faktiske ændringer af dens adresse. Det begrænser undtagelsen for den ekstra port i stedet for at tillade alle destinationer på 8443.

Få hele den aktive konfiguration parset, og gennemgå rækkefølgen af reglerne. En korrekt skrevet afvisning placeret efter en matchende regel, der tillader klienten, giver ikke den tilsigtede begrænsning.

Test det godkendte værtsnavn med dets rigtige certifikat og port, og test derefter en kontrolleret destination, der fortsat skal afvises. Når TLS-verifikation er aktiveret, kan fejl i destinationens identitet skelnes fra fejl i proxypolitikken. Fjern ikke hele CONNECT-beskyttelsen for at få én anmodning til en særlig port til at virke.