Одне правило allow у Squid означає AND; два можуть означати OR
Прочитайте комбінації ACL Squid і впорядковані правила доступу, щоб приватний проксі давав лише потрібний доступ.
Прочитайте цю політику вголос: дозвольте офісній мережі використовувати проксі для схваленого призначення. Якщо ці умови належать одна одній, тримайте їх разом у правилі.
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. Розгляньте чотири випадки: схвалений клієнт до схваленого призначення, схвалений клієнт в інше місце, інший клієнт до схваленого призначення й інший клієнт в інше місце. Якщо правила дозволяють більше випадків, ніж задумано політикою, виправте логіку, перш ніж розширювати слухача. Синтаксично правильна конфігурація все одно може виражати хибні дозволи.