Перахоп Squid супраць явнай аўтэнтыфікацыі проксі
Растлумачце, чаму звычайную явную аўтэнтыфікацыю проксі нельга проста дадаць да слухача перахопу Squid.
Кліент явнага проксі ведае, што размаўляе з проксі. Перахоплены браўзер думае, што падключыўся да сайта. Гэтая розніца мае ключавое значэнне для аўтэнтыфікацыі.
Звычайная аўтэнтыфікацыя проксі выкарыстоўвае запыт проксі і адказ аўтарызацыі проксі. Кліент, які не выбіраў проксі, не павінен проста так перадаваць уліковыя даныя проксі нечаканаму пасрэдніку.
Таму рэкамендацыі Squid па перахопу не падтрымліваюць простае спалучэнне proxy_auth з рэжымам перахопу. Працуючы памочнік базавай аўтэнтыфікацыі не змяняе таго, чым браўзер лічыць аддалены канечны пункт.
Калі ідэнтыфікаваным карыстальнікам патрэбны звычайны аўтэнтыфікаваны прамы проксі, наладзьце кліентаў яўна — напрамую або праз адпаведную кіраваную канфігурацыю проксі. Трымайце гэты слухач і яго палітыку аўтэнтыфікацыі асобна ад слухача перахопу.
Партал аўтэнтыфікацыі, сістэма ідэнтычнасці на ўзроўні сеткі або схема перахопу TLS — гэта іншы дызайн з іншымі патрабаваннямі да даверу і разгортвання. Гэта не аднарадковы рамонт адсутнай явнай праксі-сесіі.
Не вырашайце адсутнасць запыту тым, што зробіце перахоплены сэрвіс публічным або дазволіце кожнаму кліенту. Спачатку вырашыце, што патрабуецца: явная аўтэнтыфікацыя карыстальніка ці перахоп трафіку, які ніколі не наладжваўся для проксі. Ім патрэбны розныя дапушчэнні.