Squid: myportname und src mit getrennten ACLs kombinieren

Auf den ersten Blick wirkt die Konfiguration plausibel:

acl team_a myportname 3128 src 198.51.100.0/24

Eine ACL-Definition hat aber genau einen Typ. Hier ist myportname der Typ; das Wort src beginnt keinen zweiten Test. Die übrigen Wörter gehören zur Werteliste des ersten Typs. Diese Zeile drückt nicht „dieser Listener und dieses Clientnetz“ aus.

Jeder Bedingung einen Namen geben

Verwende einen Namen für den lauschenden Socket und eine getrennte Quell-ACL. Dieser Auszug verwendet Dokumentationsadressen, die durch passende Adressen der Umgebung ersetzt werden müssen:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

Setze die Allow-Regel hinter die bestehenden Schutzmaßnahmen für unsichere Zielports, eingeschränkte CONNECT-Ziele und Verwaltungszugriff. Der Auszug zeigt die Client/Listener-Bedingung; er ersetzt diese Schutzmaßnahmen nicht.

Bedingungen in einer http_access-Zeile werden mit AND verknüpft. Zwei getrennte Allow-Zeilen würden jede Bedingung unabhängig zulassen, was die Richtlinie erheblich ändern würde. Mehrere Werte innerhalb einer ACL bieten normalerweise Alternativen für diesen einen Test.

Den Ausgang getrennt wählen

Ein passender Listener lässt sich auch über tcp_outgoing_address nutzen, um eine lokale Quelladresse zu wählen. Das ist Routing-Auswahl, keine Erlaubnis, den Proxy zu benutzen. Eine Ausgangsadress-Regel kann eine abgelehnte Anfrage nicht durch http_access bringen.

Wenn eine Konfiguration mit mehreren Adressen nach einem Upgrade nicht mehr funktioniert, trenne die Belege: Ein Parse-Fehler deutet auf die Konfigurationssyntax; eine Zugriffsverweigerung auf die Regelübereinstimmung; eine erlaubte Anfrage mit falschem Ausgang auf die Ausgangsauswahl oder ein späteres NAT. Alle drei gleichzeitig zu ändern macht einen kleinen ACL-Fehler viel schwerer auffindbar.