Прихващане в Squid срещу явно удостоверяване на прокси
Обяснете защо обичайното явно удостоверяване на прокси не може просто да се добави към слушател за прихващане в Squid.
Клиент на явно прокси знае, че говори с прокси. Прихванатият браузър смята, че се е свързал със сайта. Тази разлика е в основата на удостоверяването.
Обичайното удостоверяване на прокси използва предизвикателство от прокси и отговор за оторизация на прокси. Клиент, който не е избрал прокси, не бива просто така да изпраща идентификационни данни за прокси към неочакван посредник.
Затова указанията на Squid за прихващане не поддържат простото съчетаване на proxy_auth с режим на прихващане. Работещ помощник за Basic удостоверяване не променя представата на браузъра за отдалечената крайна точка.
Ако идентифицирани потребители се нуждаят от обичайно удостоверено форуърд прокси, конфигурирайте клиентите явно — директно или чрез подходяща управлявана конфигурация на прокси. Дръжте този слушател и неговата политика за удостоверяване отделно от слушателя за прихващане.
Портал за удостоверяване, система за идентичност на мрежово ниво или схема за TLS прихващане е друг дизайн с различни изисквания за доверие и внедряване. Това не е поправка с един ред за липсващия обмен при явно прокси.
Не решавайте липсата на подкана, като направите прихващаната услуга публична или разрешите на всеки клиент. Първо решете дали изискването е явно удостоверяване на потребител, или прихващане на трафик, който никога не е бил конфигуриран за прокси. Те изискват различни допускания.