Едно правило allow в Squid означава AND; две могат да означават OR

Прочетете тази политика на глас: разрешете на офис мрежата да използва проксито за одобрената дестинация. Ако тези условия принадлежат заедно, дръжте ги заедно в правилото.

http_access allow office_clients approved_destination

И двата ACL трябва да съвпадат, за да разреши този ред заявката. Разделянето му променя политиката:

http_access allow office_clients
http_access allow approved_destination

Сега на офис клиентите може да се разреши без ограничението за дестинация, а заявките към тази дестинация — без офис ограничението, освен ако по-ранно правило не ги е отказало. Два реда не са по-четлив правопис на един ред.

Редът е част от политиката

Squid оценява правилата за достъп последователно. Първото съвпадащо решение управлява заявката. По-ранно allow all проваля внимателно по-късно ограничение; по-ранен съвпадащ отказ пречи да се стигне до по-късно разрешение.

Документацията за http_access обяснява тази последователност. Дръжте умишлен краен отказ, вместо да разчитате читателят да помни неявното поведение по подразбиране.

Много дефиниции на ACL имат различна връзка OR: един именуван ACL за източник може да изброява няколко разрешени обхвата. Това не прави самоличността на източника и дестинацията един и същ тип ACL. Дефинирайте ги отделно, после комбинирайте имената в решение за достъп.

За частен изход това влияе кой може да използва външния ви IP. Помислете за четири случая: одобрен клиент към одобрена дестинация, одобрен клиент другаде, друг клиент към одобрената дестинация и друг клиент другаде. Ако правилата разрешават повече случаи, отколкото политиката предвижда, поправете логиката, преди да разширите слушателя. Синтактично валидна конфигурация може все още да изразява грешни разрешения.