Перехоплення в Squid проти явної автентифікації проксі
Поясніть, чому звичайну явну автентифікацію проксі не можна просто додати до слухача перехоплення Squid.
Клієнт явного проксі знає, що розмовляє з проксі. Перехоплений браузер вважає, що підключився до сайту. Саме ця різниця є основою автентифікації.
Звичайна автентифікація проксі використовує запит проксі та відповідь авторизації проксі. Клієнт, який не вибрав проксі, не повинен легковажно надсилати облікові дані проксі неочікуваному посереднику.
Тому настанови Squid щодо перехоплення не підтримують простого поєднання proxy_auth з режимом перехоплення. Робочий помічник Basic-автентифікації не змінює того, чим браузер вважає віддалену кінцеву точку.
Якщо ідентифікованим користувачам потрібен звичайний автентифікований форвард-проксі, налаштуйте клієнти явно — безпосередньо або через відповідну керовану конфігурацію проксі. Тримайте цей слухач і його політику автентифікації окремо від слухача перехоплення.
Портал автентифікації, система ідентичності мережевого рівня або схема перехоплення TLS — це інша архітектура з іншими вимогами до довіри та розгортання. Це не однорядкове виправлення відсутнього обміну явного проксі.
Не розв'язуйте відсутність запиту, роблячи перехоплений сервіс публічним або дозволяючи кожного клієнта. Спершу вирішіть, чи потрібна явна автентифікація користувача, чи перехоплення трафіку, який ніколи не налаштовувався для проксі. Їм потрібні різні припущення.