Zezwalaj na jeden cel Squid bez uwierzytelniania proxy

Strona monitoringu musi działać bez logowania do proxy. Oczywista reguła to http_access allow status_site. Umieszczona przed uwierzytelnianiem może też przyznać wyjątek klientom, których nigdy nie zamierzałeś obsługiwać.

W Squid 6 lub 7 trzymaj warunki wyjątku razem. Po istniejących zabezpieczeniach zarządzania, niebezpiecznych portów, CONNECT i usług lokalnych odpowiednia część może wyglądać tak:

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

Sieć i nazwa hosta to placeholdery. Uwierzytelnianie nadal wymaga istniejącej konfiguracji pomocnika. To jest część wyjątku w polityce dostępu, a nie pełna konfiguracja proxy.

Pierwszy wiersz zezwala wybranym klientom na ten cel bez oceniania ACL logowania. Następny zezwala tym klientom gdzie indziej dopiero po uwierzytelnieniu. Wcześniejsze szerokie zezwolenia lub późniejsze alternatywne ścieżki mogą zmienić wynik, więc przeczytaj całą uporządkowaną politykę, łącznie z dołączonymi plikami.

Nie przenoś wyjątku ponad zabezpieczenia portu docelowego tylko po to, by uniknąć monitu. Autoryzowana witryna na niezamierzonym porcie to nadal inna trasa. Zdecyduj też, czy kwalifikować ma się dokładny host, czy jego subdomeny, zamiast dodawać niepotrzebnie szeroki sufiks.

Wyjątek nazwy hosta obejmuje pasujący cel, a nie każdą zależność ładowaną przez jego stronę. Przekierowania i zasoby stron trzecich mogą zgodnie z prawem napotkać zwykły wymóg logowania.

Dla zwykłego HTTP proxy może użyć dokładniejszych informacji o URL, gdy to właściwe. Zwykłe żądanie HTTPS CONNECT nie ujawnia ścieżki strony, więc reguły „tylko jedna strona” nie można wywnioskować z wyjątku tunelu dla całego hosta.