Jedna reguła allow w Squidzie oznacza AND; dwie mogą oznaczać OR

Przeczytaj tę politykę na głos: pozwól sieci biurowej korzystać z proxy dla zatwierdzonego celu. Jeśli te warunki należą do siebie, trzymaj je razem w regule.

http_access allow office_clients approved_destination

Oba ACL muszą się zgadzać, aby ta linia zezwalała na żądanie. Rozdzielenie jej zmienia politykę:

http_access allow office_clients
http_access allow approved_destination

Klienci biurowi mogą teraz być dozwoleni bez ograniczenia celu, a żądania do tego celu bez ograniczenia biurowego, chyba że wcześniejsza reguła je odrzuciła. Dwie linie nie są czytelniejszą pisownią jednej linii.

Kolejność jest częścią polityki

Squid ocenia reguły dostępu po kolei. Pierwsza pasująca decyzja steruje żądaniem. Wcześniejsze allow all unieważnia staranne późniejsze ograniczenie; wcześniejsza pasująca odmowa uniemożliwia dotarcie do późniejszego zezwolenia.

Dokumentacja http_access wyjaśnia tę kolejność. Zachowaj świadomą końcową odmowę zamiast liczyć na to, że czytelnik zapamięta domyślne zachowanie dorozumiane.

Wiele definicji ACL ma inną relację OR: jedna nazwana ACL źródłowa może wymieniać kilka dozwolonych zakresów. To nie czyni tożsamości źródła i celu tym samym typem ACL. Zdefiniuj je osobno, a następnie połącz nazwy w decyzji dostępu.

W przypadku prywatnego wyjścia wpływa to na to, kto może używać twojego zewnętrznego IP. Rozważ cztery przypadki: zatwierdzony klient do zatwierdzonego celu, zatwierdzony klient gdzie indziej, inny klient do zatwierdzonego celu i inny klient gdzie indziej. Jeśli reguły pozwalają na więcej przypadków, niż zakłada polityka, popraw logikę, zanim poszerzysz listener. Składniowo poprawna konfiguracja wciąż może wyrażać błędne uprawnienia.