Tillat éin ekstra HTTPS-port gjennom Squid

Ei HTTPS-teneste på port 8443 kan mislukkast gjennom ein rett konfigurert Squid-proxy sjølv om vanleg HTTPS på 443 verkar. Undersøk CONNECT-avvisinga og reglane for målportar før du endrar proxyprotokollen til klienten.

I ein vanleg tilgangspolicy for Squid 6.13 er to kontrollar viktige: Målet må passere Safe_ports, og CONNECT må passere SSL_ports. Viss porten berre vert lagd til i éin ACL, kan den andre avvisinga framleis gjelde.

Utvid dei eksisterande definisjonane med omtanke

For ein policy som tillèt vanlege vevportar og éin ekstra HTTPS-port:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Byt ut eller rediger dei aktuelle definisjonane slik at eit uventa eldre sett med verdiar ikkje vert ståande. Ta vare på dei vanlege reglane som avviser utrygge portar og CONNECT, og dei tiltenkte klientavgrensingane.

Hald unntaket snevert

Viss den ekstra porten berre trengst for eitt kontrollert mål, legg du til ei målretta avvising før regelen som tillèt 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

Adressa er ein plasshaldar for dokumentasjon. Bruk målet du administrerer eller har løyve til å nå, og ta omsyn til faktiske endringar i adressa. Dette avgrensar unntaket for den ekstra porten i staden for å tillate alle mål på 8443.

Lat heile den aktive konfigurasjonen verte parsa, og gå gjennom rekkjefølgja på reglane. Ei rett skriven avvising etter ein samsvarande regel som tillèt klienten, gjev ikkje den tiltenkte avgrensinga.

Test det godkjende vertsnamnet med det faktiske sertifikatet og porten, og test deretter eit kontrollert mål som framleis skal avvisast. Hald TLS-verifisering påslått for å skilje feil i identiteten til målet frå feil i proxypolicyen. Ikkje fjern heile CONNECT-vernet for å få éin førespurnad til ein eigendefinert port til å verke.