Перехват в Squid и явная аутентификация прокси
Объясните, почему обычную явную аутентификацию прокси нельзя просто добавить к слушателю перехвата Squid.
Клиент явного прокси знает, что разговаривает с прокси. Перехваченный браузер думает, что подключился к сайту. Именно это различие лежит в основе аутентификации.
Обычная аутентификация прокси использует запрос прокси и ответ авторизации прокси. Клиент, который не выбирал прокси, не должен легкомысленно отправлять учётные данные прокси неожиданному посреднику.
Поэтому рекомендации Squid по перехвату не поддерживают простое совмещение proxy_auth с режимом перехвата. Работающий помощник Basic-аутентификации не меняет того, чем браузер считает удалённую конечную точку.
Если идентифицированным пользователям нужен обычный аутентифицированный форвард-прокси, настройте клиентов явно — напрямую или через подходящую управляемую конфигурацию прокси. Держите этот слушатель и его политику аутентификации отдельно от слушателя перехвата.
Портал аутентификации, система идентичности сетевого уровня или схема перехвата TLS — это другая архитектура с иными требованиями к доверию и развёртыванию. Это не однострочное исправление отсутствующего обмена явного прокси.
Не решайте отсутствие запроса, делая перехваченный сервис публичным или разрешая любого клиента. Сначала решите, требуется ли явная аутентификация пользователя или перехват трафика, который никогда не настраивался для прокси. Им нужны разные допущения.