Wymagaj zarówno logowania Squid, jak i właściwego IP klienta

Prawidłowe hasło to tylko połowa tej polityki: konto powinno działać również z jednego zatwierdzonego adresu klienta. W Squidzie umieszczenie obu kontroli w tej samej regule dostępu jest różnicą między tym wymaganiem a dwiema osobnymi drogami wejścia.

Zakładając, że uwierzytelnianie jest już skonfigurowane, na przykład konfiguracja Squid 6.13 NCSA, podstawowa polityka jest następująca:

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

Użyj źródła, które Squid faktycznie otrzymuje; przykład to adres dokumentacyjny. Zachowaj wcześniejsze zabezpieczenia dla niebezpiecznych portów docelowych, usług lokalnych i ruchu CONNECT. Ten fragment pokazuje połączony warunek, a nie pełną konfigurację nasłuchu.

Sprawdź reguły powyżej

Wcześniejsze szerokie zezwolenie może przyjąć żądanie, zanim dotrze ono do nowego warunku. Dokumentacja http_access opisuje uporządkowane dopasowanie. Przeczytaj całą sekwencję, w tym dołączone pliki.

Jedno zezwolenie dla nazwy użytkownika, a drugie dla źródła nie wymagają obu. Każda linia może odnieść sukces niezależnie. To inna polityka.

ACL proxy_auth zależy od pomocnika uwierzytelniania. Zdefiniowanie go nie jest sposobem na utworzenie użytkownika ani sprawdzenie hasła. Ten przykład dotyczy jawnego proxy, którego klienci mogą odpowiadać na wyzwania uwierzytelniania proxy.

Tożsamość źródła ma również ograniczenia. Osoby za jednym NAT mogą dzielić adres, a przenośny komputer może zmieniać adresy. Dodatkowy warunek zawęża użyteczną lokalizację sieciową konta; nie identyfikuje niezawodnie fizycznego komputera. Upewnij się, że to ograniczenie odpowiada powodowi, dla którego pierwotnie dodano warunek.