En HTTPS-tjeneste på port 8443 kan feile gjennom en korrekt konfigurert Squid-proxy selv om vanlig HTTPS på 443 fungerer. Se på CONNECT-avvisningen og policyen for målporter før du endrer klientens proxyprotokoll.

I en typisk tilgangspolicy for Squid 6.13 er to kontroller avgjørende: Målet må passere Safe_ports, og CONNECT må passere SSL_ports. Legger du porten til bare én ACL, kan den andre avvisningen fortsatt være i kraft.

Utvid eksisterende definisjoner med omtanke

For en policy som tillater vanlige webporter og én ekstra HTTPS-port:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Bytt ut eller rediger de tilsvarende definisjonene, slik at en uventet gammel samling verdier ikke blir stående. Bevar de vanlige reglene som avviser usikre porter og CONNECT, og de tiltenkte klientbegrensningene.

Begrens unntaket

Hvis den ekstra porten bare er nødvendig for ett kontrollert mål, legg til en målrettet avvisning før regelen som tillater 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 plassholder til dokumentasjon. Bruk målet du administrerer eller har lov til å nå, og ta høyde for faktiske adresseendringer. Dette begrenser unntaket for den ekstra porten fremfor å tillate alle mål på 8443.

Få hele den aktive konfigurasjonen parset og kontroller regelrekkefølgen. En korrekt skrevet avvisning plassert etter en matchende regel som tillater klienten, vil ikke gi den ønskede begrensningen.

Test det godkjente vertsnavnet med det virkelige sertifikatet og porten, og test så et kontrollert mål som fortsatt skal nektes tilgang. La TLS-verifisering være aktivert for å skille feil i målets identitet fra feil i proxypolicyen. Ikke fjern hele CONNECT-vernet for å få én forespørsel på en egendefinert port til å fungere.

Relaterte artikler