Én Squid-allow-regel betyder AND; to kan betyde OR

Læs denne politik højt: tillad kontorets netværk at bruge proxyen til den godkendte destination. Hvis disse betingelser hører sammen, så hold dem sammen i reglen.

http_access allow office_clients approved_destination

Begge ACL'er skal matche, for at den linje tillader anmodningen. At dele den ændrer politikken:

http_access allow office_clients
http_access allow approved_destination

Kontorklienter kan nu tillades uden destinationsbegrænsningen, og anmodninger til den destination uden kontorbegrænsningen, medmindre en tidligere regel afviste dem. To linjer er ikke en mere læsbar stavemåde for én linje.

Rækkefølge er en del af politikken

Squid vurderer adgangsregler i rækkefølge. Den første matchende beslutning styrer anmodningen. En tidligere allow all omstøder en omhyggelig senere begrænsning; en tidligere matchende afvisning forhindrer at nå en senere tilladelse.

http_access-dokumentationen forklarer denne rækkefølge. Behold en bevidst endelig afvisning i stedet for at regne med, at læseren husker den implicitte standardadfærd.

Mange ACL-definitioner har en anden OR-relation: én navngivet kilde-ACL kan liste flere tilladte intervaller. Det gør ikke kilde- og destinationsidentitet til samme ACL-type. Definer dem hver for sig, og kombinér så navnene i en adgangsbeslutning.

For en privat udgang påvirker det, hvem der kan bruge din udgående IP. Overvej fire tilfælde: godkendt klient til godkendt destination, godkendt klient andre steder, en anden klient til den godkendte destination, og en anden klient andre steder. Hvis reglerne tillader flere tilfælde, end politikken tilsigter, så ret logikken, før du udvider lytteren. En syntaktisk gyldig konfiguration kan stadig udtrykke forkerte tilladelser.