Én Squid-allow-regel betyr AND; to kan bety OR

Les denne policyen høyt: tillat kontornettverket å bruke proxyen for den godkjente destinasjonen. Hvis disse vilkårene hører sammen, hold dem sammen i regelen.

http_access allow office_clients approved_destination

Begge ACL-ene må stemme for at linjen skal tillate forespørselen. Å dele den endrer policyen:

http_access allow office_clients
http_access allow approved_destination

Kontorklienter kan nå tillates uten destinasjonsbegrensningen, og forespørsler til den destinasjonen uten kontorbegrensningen, med mindre en tidligere regel avviste dem. To linjer er ikke en mer lesbar skrivemåte for én linje.

Rekkefølgen er en del av policyen

Squid vurderer tilgangsregler i rekkefølge. Den første samsvarende beslutningen styrer forespørselen. En tidligere allow all overstyrer en nøye senere begrensning; en tidligere samsvarende avvisning hindrer å nå en senere tillatelse.

http_access-dokumentasjonen forklarer denne rekkefølgen. Behold en bevisst endelig avvisning i stedet for å stole på at leseren husker den implisitte standardatferden.

Mange ACL-definisjoner har en annen OR-relasjon: én navngitt kilde-ACL kan liste flere tillatte områder. Det gjør ikke kilde- og destinasjonsidentiteten til samme ACL-type. Definer dem hver for seg, og kombiner deretter navnene i en tilgangsbeslutning.

For en privat utgang påvirker dette hvem som kan bruke din utgående IP. Vurder fire tilfeller: godkjent klient til godkjent destinasjon, godkjent klient andre steder, en annen klient til den godkjente destinasjonen, og en annen klient andre steder. Hvis reglene tillater flere tilfeller enn policyen har tenkt, rett logikken før du utvider lytteren. En syntaktisk gyldig konfigurasjon kan fortsatt uttrykke feil tillatelser.