Tillåt en extra HTTPS-port genom Squid

Uppdatera båda port-ACL:erna i Squid 6.13 och begränsa målet när en godkänd HTTPS-tjänst använder port 8443.

En HTTPS-tjänst på port 8443 kan misslyckas genom en korrekt konfigurerad Squid-proxy även när vanlig HTTPS på 443 fungerar. Undersök CONNECT-nekandet och policyn för målportar innan du ändrar klientens proxyprotokoll.

I en typisk åtkomstpolicy för Squid 6.13 är två kontroller viktiga: målet måste passera Safe_ports och CONNECT måste passera SSL_ports. Om porten bara läggs till i en ACL kan det andra nekandet fortsätta gälla.

Utöka de befintliga definitionerna med eftertanke

För en policy som tillåter vanliga webbportar och en extra HTTPS-port:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Ersätt eller redigera motsvarande definitioner så att en oväntad äldre uppsättning värden inte blir kvar. Behåll de vanliga reglerna som nekar osäkra portar och CONNECT samt de avsedda klientbegränsningarna.

Håll undantaget snävt

Om den extra porten bara behövs för ett kontrollerat mål, lägg till ett riktat nekande före regeln som tillåter 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 är en platshållare för dokumentation. Använd det mål du administrerar eller har behörighet att komma åt och ta hänsyn till faktiska ändringar av dess adress. Det begränsar undantaget för den extra porten i stället för att tillåta alla mål på 8443.

Låt hela den aktiva konfigurationen parsas och granska regelordningen. Ett korrekt skrivet nekande efter en matchande regel som tillåter klienten ger inte den avsedda begränsningen.

Testa det godkända värdnamnet med dess riktiga certifikat och port och testa sedan ett kontrollerat mål som fortfarande ska nekas. Behåll TLS-verifieringen aktiverad för att skilja fel i målets identitet från fel i proxypolicyn. Ta inte bort hela CONNECT-skyddet för att få en enda begäran till en anpassad port att fungera.

Relaterade artiklar