Laat een ekstra HTTPS-poort deur Squid toe

’n HTTPS-diens op poort 8443 kan deur ’n korrek opgestelde Squid-proxy misluk, selfs wanneer gewone HTTPS op 443 werk. Ondersoek die CONNECT-weiering en die bestemmingspoortbeleid voordat jy die kliënt se proxyprotokol verander.

In ’n tipiese Squid 6.13-toegangsbeleid is twee kontroles belangrik: die bestemming moet Safe_ports slaag, en CONNECT moet SSL_ports slaag. As die poort by slegs een ACL gevoeg word, kan die ander weiering steeds geld.

Brei die bestaande definisies doelbewus uit

Vir ’n beleid wat gewone webpoorte en een bykomende HTTPS-poort toelaat:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Vervang of wysig die betrokke definisies sodat ’n onverwagte ou stel waardes nie bly geld nie. Behou die gewone reëls wat onveilige poorte en CONNECT weier, asook die bedoelde kliëntbeperkings.

Hou die uitsondering beperk

As die bykomende poort net vir een beheerde bestemming nodig is, voeg ’n gerigte weiering vóór die kliënt se toelaatreël by:

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

Die adres is ’n plekhouer vir dokumentasie. Gebruik die bestemming wat jy bestuur of gemagtig is om te besoek, en hou rekening met werklike adresveranderings. Dit beperk die ekstra-poortuitsondering in plaas daarvan om elke bestemming op 8443 toe te laat.

Ontleed die volledige aktiewe konfigurasie en hersien die reëlvolgorde. ’n Korrek geskryfde weiering ná ’n ooreenstemmende kliënttoelaatreël bied nie die bedoelde beperking nie.

Toets die goedgekeurde gasheernaam met sy werklike sertifikaat en poort; toets dan ’n beheerde bestemming wat steeds geweier moet word. Laat TLS-verifikasie aangeskakel om bestemmingsidentiteitsfoute van proxybeleidsfoute te onderskei. Moenie die hele CONNECT-beskerming verwyder om een versoek na ’n pasgemaakte poort te laat werk nie.