Klienti i një proxy-t eksplicit e di se po flet me një proxy. Shfletuesi i ndërhyer mendon se është lidhur me faqen. Ky ndryshim është thelbësor për vërtetimin.

Vërtetimi i zakonshëm i proxy-t përdor një sfidë proxy dhe një përgjigje autorizimi proxy. Një klient që nuk zgjodhi proxy nuk duhet t'i dërgojë pa kujdes kredencialet e proxy-t një ndërmjetësi të papritur.

Prandaj udhëzimet e Squid për ndërhyrjen nuk mbështesin thjesht kombinimin e proxy_auth me modalitetin e ndërhyrjes. Një ndihmës funksional i vërtetimit Basic nuk ndryshon atë që shfletuesi mendon se është pika e largët.

Nëse përdoruesit e identifikuar kanë nevojë për një proxy përpara të vërtetuar të zakonshëm, konfiguroni klientët në mënyrë eksplicite, drejtpërdrejt ose përmes një konfigurimi të menaxhuar të përshtatshëm proxy. Mbani atë dëgjues dhe politikën e tij të vërtetimit të ndara nga një dëgjues ndërhyrjeje.

Një portal vërtetimi, një sistem identiteti në nivel rrjeti ose një skemë ndërhyrjeje TLS janë një dizajn tjetër me kërkesa të ndryshme besimi dhe vendosjeje. Nuk është një rregullim një-rresht për shkëmbimin e munguar të proxy-t eksplicit.

Mos e zgjidhni mungesën e një kërkese duke e bërë publik shërbimin e ndërhyer ose duke lejuar çdo klient. Së pari vendosni nëse kërkesa është vërtetim eksplicit i përdoruesit ose ndërhyrje e trafikut që nuk u konfigurua kurrë për proxy. Të dyja kërkojnë supozime të ndryshme.

Artikuj të ngjashëm