Tillåt en Squid-destination utan proxy-autentisering

En övervakningssida måste fungera utan proxy-inloggning. Den uppenbara regeln är http_access allow status_site. Placerad före autentiseringen kan den också ge undantaget till klienter du aldrig avsåg att betjäna.

För Squid 6 eller 7 håller du undantagets villkor tillsammans. Efter de befintliga skydden för administration, osäkra portar, CONNECT och lokala tjänster kan den relevanta delen se ut så här:

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

Nätverket och värdnamnet är platshållare. Autentiseringen behöver fortfarande sin befintliga hjälparkonfiguration. Detta är undantagsdelen av en åtkomstpolicy, inte en fullständig proxykonfiguration.

Den första raden tillåter de valda klienterna den destinationen utan att utvärdera inloggnings-ACL:n. Nästa tillåter dessa klienter på andra håll först efter autentisering. Tidigare breda tillåtelser eller senare alternativa vägar kan ändra resultatet, så läs hela den ordnade policyn, inklusive inkluderade filer.

Flytta inte undantaget ovanför skydden för destinationsporten bara för att undvika en fråga. En auktoriserad webbplats på en oavsiktlig port är fortfarande en annan väg. Bestäm också om den exakta värden eller dess underdomäner ska kvalificera i stället för att lägga till ett onödigt brett suffix.

Ett värdnamnsundantag täcker den matchande destinationen, inte varje beroende som laddas av dess sida. Omdirigeringar och tredjepartsresurser kan legitimt möta det vanliga inloggningskravet.

För vanlig HTTP kan en proxy använda finare URL-information där det passar. En vanlig HTTPS CONNECT-begäran exponerar inte sidans sökväg, så en regel om ”bara en sida” kan inte härledas från ett tunnelundantag för hela värden.