Дозволити одне призначення Squid без автентифікації проксі
Зберігайте обмеження джерела й призначення навколо навмисного винятку автентифікації в Squid.
Сторінка моніторингу має працювати без входу через проксі. Очевидне правило — http_access allow status_site. Якщо розмістити його до автентифікації, воно може також надати виняток клієнтам, яких ви ніколи не планували обслуговувати.
Для Squid 6 або 7 тримайте умови винятку разом. Після наявних засобів захисту для керування, небезпечних портів, CONNECT і локальних служб відповідна частина може виглядати так:
acl office_clients src 192.0.2.0/24
acl status_site dstdomain status.example.net
acl signed_in proxy_auth REQUIRED
http_access allow office_clients status_site
http_access allow office_clients signed_in
http_access deny all
Мережа й ім'я хоста — це заповнювачі. Автентифікація все ще потребує своєї наявної конфігурації помічника. Це частина винятку в політиці доступу, а не повна конфігурація проксі.
Перший рядок дозволяє вибраним клієнтам це призначення без оцінювання ACL входу. Наступний дозволяє цим клієнтам інші місця лише після автентифікації. Раніші широкі дозволи або пізніші альтернативні шляхи можуть змінити результат, тому читайте всю впорядковану політику, включно з включеними файлами.
Не переміщуйте виняток вище захисту порту призначення лише щоб уникнути запиту. Авторизований сайт на ненавмисному порту все одно є іншим маршрутом. Також вирішіть, чи мають кваліфікуватися точний хост або його піддомени, замість додавання зайво широкого суфікса.
Виняток для імені хоста охоплює відповідне призначення, а не кожну залежність, яку завантажує його сторінка. Переспрямування й сторонні ресурси можуть законно зіткнутися зі звичайною вимогою входу.
Для простого HTTP проксі може використовувати точнішу інформацію про URL, де це доречно. Звичайний запит HTTPS CONNECT не розкриває шлях сторінки, тому правило «лише одна сторінка» не можна вивести з винятку тунелю для всього хоста.