Yksi Squidin allow-sääntö tarkoittaa AND; kaksi voi tarkoittaa OR

Lue tämä käytäntö ääneen: salli toimiston verkon käyttää välityspalvelinta hyväksyttyyn kohteeseen. Jos nämä ehdot kuuluvat yhteen, pidä ne yhdessä säännössä.

http_access allow office_clients approved_destination

Molempien ACL:ien on täsmättävä, jotta rivi sallii pyynnön. Sen jakaminen muuttaa käytäntöä:

http_access allow office_clients
http_access allow approved_destination

Toimiston asiakkaat voidaan nyt sallia ilman kohderajoitusta, ja pyynnöt kyseiseen kohteeseen ilman toimistorajoitusta, ellei aiempi sääntö ole hylännyt niitä. Kaksi riviä ei ole yhden rivin luettavampi kirjoitusasu.

Järjestys on osa käytäntöä

Squid arvioi käyttösäännöt peräkkäin. Ensimmäinen täsmäävä päätös ohjaa pyyntöä. Aiempi allow all kumoaa huolellisen myöhemmän rajoituksen; aiempi täsmäävä hylkäys estää myöhemmän sallinnan saavuttamisen.

http_access-dokumentaatio selittää tämän järjestyksen. Pidä tarkoituksellinen lopullinen hylkäys sen sijaan, että luottaisit lukijan muistavan implisiittisen oletuskäyttäytymisen.

Monilla ACL-määritelmillä on erilainen OR-suhde: yksi nimetty lähde-ACL voi luetella useita sallittuja alueita. Tämä ei tee lähteen ja kohteen identiteetistä samaa ACL-tyyppiä. Määrittele ne erikseen ja yhdistä sitten nimet käyttöpäätöksessä.

Yksityiselle ulostulolle tämä vaikuttaa siihen, kuka voi käyttää ulkoista IP-osoitettasi. Harkitse neljää tapausta: hyväksytty asiakas hyväksyttyyn kohteeseen, hyväksytty asiakas muualle, toinen asiakas hyväksyttyyn kohteeseen ja toinen asiakas muualle. Jos säännöt sallivat enemmän tapauksia kuin käytäntö tarkoittaa, korjaa logiikka ennen kuuntelijan laajentamista. Syntaktisesti kelvollinen kokoonpano voi silti ilmaista vääriä käyttöoikeuksia.