Поєднання myportname і src у Squid за допомогою окремих ACL

Поєднайте іменований listener Squid із дозволеною клієнтською мережею, не вміщуючи два типи ACL в одне визначення.

Конфігурація на перший погляд виглядає правдоподібно:

acl team_a myportname 3128 src 198.51.100.0/24

Але визначення ACL має лише один тип. Тут myportname — це тип; додавання слова src не запускає другу перевірку. Решта слів належать до списку значень першого типу. Цей рядок не виражає «цей listener і ця клієнтська мережа».

Дайте ім’я кожній умові

Використайте ім’я для слухаючого сокета й окремий ACL джерела. Цей фрагмент використовує документаційні адреси, які треба замінити адресами, придатними для розгортання:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

Розмістіть правило дозволу після наявних захистів для небезпечних портів призначення, обмежених цілей CONNECT і адміністративного доступу. Фрагмент ілюструє умову клієнта/listener; він не замінює ці захисти.

Умови в одному рядку http_access поєднуються через AND. Два окремі рядки дозволу пропускали б кожну умову незалежно, що суттєво змінило б політику. Кілька значень у межах одного ACL зазвичай дають альтернативи для цієї єдиної перевірки.

Виберіть вихід окремо

Відповідний listener можна також використати через tcp_outgoing_address, щоб вибрати локальну адресу джерела. Це вибір маршрутизації, а не дозвіл користуватися проксі. Правило адреси виходу не може пропустити відхилений запит через http_access.

Якщо багатоадресна конфігурація перестає працювати після оновлення, розділіть докази: помилка розбору вказує на синтаксис конфігурації; відмова в доступі — на збіг правил; дозволений запит із неправильним виходом — на вибір виходу або пізніший NAT. Зміна всіх трьох одразу робить невелику помилку ACL значно важчою для пошуку.

Схожі статті