Eén Squid-allow-regel betekent AND; twee kunnen OR betekenen

Lees dit beleid hardop: sta het kantoornetwerk toe de proxy te gebruiken voor de goedgekeurde bestemming. Als die voorwaarden bij elkaar horen, houd ze dan bij elkaar in de regel.

http_access allow office_clients approved_destination

Beide ACL's moeten overeenkomen wil die regel het verzoek toestaan. Het splitsen ervan verandert het beleid:

http_access allow office_clients
http_access allow approved_destination

Kantoorclients kunnen nu worden toegestaan zonder de bestemmingsbeperking, en verzoeken naar die bestemming zonder de kantoorbeperking, tenzij een eerdere regel ze heeft geweigerd. Twee regels zijn geen leesbaarder spelling van één regel.

Volgorde is deel van het beleid

Squid beoordeelt toegangsregels op volgorde. De eerste overeenkomende beslissing beheerst het verzoek. Een eerdere allow all tenietdoet een zorgvuldige latere beperking; een eerdere overeenkomende weigering voorkomt dat een latere toestemming wordt bereikt.

De http_access-documentatie legt deze volgorde uit. Houd een bewuste laatste weigering aan in plaats van te vertrouwen op het geheugen van de lezer voor het impliciete standaardgedrag.

Veel ACL-definities hebben een andere OR-relatie: één genoemde bron-ACL kan meerdere toegestane bereiken opsommen. Dat maakt de identiteit van bron en bestemming niet hetzelfde ACL-type. Definieer ze apart en combineer daarna de namen in een toegangsbeslissing.

Voor een privé-uitgang beïnvloedt dit wie je uitgaande IP kan gebruiken. Overweeg vier gevallen: goedgekeurde client naar goedgekeurde bestemming, goedgekeurde client elders, een andere client naar de goedgekeurde bestemming, en een andere client elders. Als de regels meer gevallen toestaan dan het beleid bedoelt, corrigeer de logica voordat je de listener verbreedt. Een syntactisch geldige configuratie kan nog steeds verkeerde rechten uitdrukken.