Una regola allow di Squid significa AND; due possono significare OR

Leggi questa politica ad alta voce: consenti alla rete dell'ufficio di usare il proxy per la destinazione approvata. Se queste condizioni vanno insieme, tienile insieme nella regola.

http_access allow office_clients approved_destination

Entrambe le ACL devono corrispondere perché quella riga consenta la richiesta. Dividerla cambia la politica:

http_access allow office_clients
http_access allow approved_destination

Ora i client dell'ufficio possono essere consentiti senza la restrizione di destinazione, e le richieste verso quella destinazione senza la restrizione d'ufficio, a meno che una regola precedente le abbia negate. Due righe non sono una grafia più leggibile di una sola.

L'ordine fa parte della politica

Squid valuta le regole di accesso in sequenza. La prima decisione corrispondente controlla la richiesta. Un allow all precedente annulla una restrizione successiva accurata; un rifiuto corrispondente precedente impedisce di raggiungere un permesso successivo.

La documentazione di http_access spiega questa sequenza. Mantieni un rifiuto finale deliberato invece di contare sulla memoria del lettore per il comportamento implicito predefinito.

Molte definizioni di ACL hanno una relazione OR diversa: una ACL di origine con nome può elencare più intervalli consentiti. Ciò non rende l'identità di origine e destinazione lo stesso tipo di ACL. Definiscile separatamente, poi combina i nomi in una decisione di accesso.

Per un'uscita privata, questo influisce su chi può usare il tuo IP esterno. Considera quattro casi: client approvato verso destinazione approvata, client approvato altrove, un altro client verso la destinazione approvata e un altro client altrove. Se le regole consentono più casi di quanti la politica intenda, correggi la logica prima di ampliare il listener. Una configurazione sintatticamente valida può comunque esprimere permessi errati.