Une règle allow de Squid signifie AND ; deux peuvent signifier OR

Lisez cette politique à voix haute : autorisez le réseau du bureau à utiliser le proxy pour la destination approuvée. Si ces conditions vont ensemble, gardez-les ensemble dans la règle.

http_access allow office_clients approved_destination

Les deux ACL doivent correspondre pour que cette ligne autorise la requête. La scinder change la politique :

http_access allow office_clients
http_access allow approved_destination

Les clients du bureau peuvent désormais être autorisés sans la restriction de destination, et les requêtes vers cette destination sans la restriction de bureau, sauf si une règle antérieure les a refusées. Deux lignes ne sont pas une orthographe plus lisible d'une seule.

L'ordre fait partie de la politique

Squid évalue les règles d'accès dans l'ordre. La première décision correspondante contrôle la requête. Un allow all antérieur annule une restriction ultérieure soignée ; un refus correspondant antérieur empêche d'atteindre une autorisation ultérieure.

La documentation http_access explique cet ordre. Conservez un refus final délibéré plutôt que de compter sur la mémoire du lecteur pour le comportement implicite par défaut.

Beaucoup de définitions d'ACL ont une relation OR différente : une ACL source nommée peut lister plusieurs plages autorisées. Cela ne fait pas de l'identité de source et de destination le même type d'ACL. Définissez-les séparément, puis combinez les noms dans une décision d'accès.

Pour une sortie privée, cela affecte qui peut utiliser votre IP sortante. Considérez quatre cas : client approuvé vers destination approuvée, client approuvé ailleurs, autre client vers la destination approuvée, et autre client ailleurs. Si les règles autorisent plus de cas que la politique ne le prévoit, corrigez la logique avant d'élargir l'écouteur. Une configuration syntaxiquement valide peut encore exprimer des permissions erronées.