Прочитайте цю політику вголос: дозвольте офісній мережі використовувати проксі для схваленого призначення. Якщо ці умови належать одна одній, тримайте їх разом у правилі.

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

Схожі статті