Eine Squid-Allow-Regel bedeutet AND; zwei können OR bedeuten

Lesen Sie diese Richtlinie laut vor: Erlauben Sie dem Büronetzwerk, den Proxy für das genehmigte Ziel zu nutzen. Wenn diese Bedingungen zusammengehören, halten Sie sie in der Regel zusammen.

http_access allow office_clients approved_destination

Beide ACLs müssen übereinstimmen, damit diese Zeile die Anfrage erlaubt. Wird sie geteilt, ändert sich die Richtlinie:

http_access allow office_clients
http_access allow approved_destination

Büroclients dürfen nun ohne die Zielbeschränkung erlaubt werden, und Anfragen an dieses Ziel ohne die Bürobeschränkung, sofern sie nicht eine frühere Regel abgelehnt hat. Zwei Zeilen sind keine lesbarere Schreibweise für eine Zeile.

Die Reihenfolge gehört zur Richtlinie

Squid wertet Zugriffsregeln der Reihe nach aus. Die erste passende Entscheidung steuert die Anfrage. Ein früheres allow all entkräftet eine sorgfältige spätere Beschränkung; eine frühere passende Ablehnung verhindert das Erreichen einer späteren Erlaubnis.

Die http_access-Dokumentation erklärt diese Reihenfolge. Behalten Sie eine bewusste abschließende Ablehnung, statt darauf zu vertrauen, dass Leser das implizite Standardverhalten erinnern.

Viele ACL-Definitionen haben eine andere OR-Beziehung: Eine benannte Quell-ACL kann mehrere erlaubte Bereiche auflisten. Das macht Quell- und Zielidentität nicht zum selben ACL-Typ. Definieren Sie sie getrennt und kombinieren Sie dann die Namen in einer Zugriffsentscheidung.

Bei einem privaten Ausgang betrifft das, wer Ihre nach außen sichtbare IP nutzen darf. Betrachten Sie vier Fälle: genehmigter Client zum genehmigten Ziel, genehmigter Client anderswo, ein anderer Client zum genehmigten Ziel und ein anderer Client anderswo. Wenn die Regeln mehr Fälle erlauben, als die Richtlinie beabsichtigt, korrigieren Sie die Logik, bevor Sie den Listener erweitern. Eine syntaktisch gültige Konfiguration kann dennoch falsche Berechtigungen ausdrücken.