Eén Squid-bestemming toestaan zonder proxy-authenticatie

Een monitoringspagina moet zonder proxylogin werken. De voor de hand liggende regel is http_access allow status_site. Vóór authenticatie geplaatst, kan die de uitzondering ook geven aan clients die u nooit van plan was te bedienen.

Voor Squid 6 of 7 houdt u de voorwaarden van de uitzondering bij elkaar. Na de bestaande beveiligingen voor beheer, onveilige poorten, CONNECT en lokale diensten kan het relevante deel er zo uitzien:

acl office_clients src 192.0.2.0/24
acl status_site dstdomain status.example.net
acl signed_in proxy_auth REQUIRED

http_access allow office_clients status_site
http_access allow office_clients signed_in
http_access deny all

Het netwerk en de hostnaam zijn plaatsaanduidingen. Authenticatie heeft nog steeds de bestaande helperconfiguratie nodig. Dit is het uitzonderingsdeel van een toegangsbeleid, geen volledige proxyconfiguratie.

De eerste regel staat de geselecteerde clients die bestemming toe zonder de login-ACL te evalueren. De volgende staat die clients elders pas na authenticatie toe. Eerdere brede toestemmingen of latere alternatieve paden kunnen het resultaat veranderen, dus lees het volledige geordende beleid, inclusief inbegrepen bestanden.

Verplaats de uitzondering niet boven de beschermingen van de bestemmingspoort alleen om een prompt te vermijden. Een geautoriseerde site op een onbedoelde poort is nog steeds een andere route. Bepaal ook of de exacte host of zijn subdomeinen moeten kwalificeren in plaats van een onnodig breed achtervoegsel toe te voegen.

Een hostnaamuitzondering dekt de overeenkomende bestemming, niet elke afhankelijkheid die door de pagina wordt geladen. Omleidingen en externe assets kunnen legitiem de normale loginvereiste tegenkomen.

Voor gewoon HTTP kan een proxy waar passend fijnere URL-informatie gebruiken. Een gewoon HTTPS CONNECT-verzoek legt het paginapad niet bloot, dus een regel 'slechts één pagina' kan niet worden afgeleid uit een tunneluitzondering voor de hele host.