Protokol PROXY v Squidu: zaupajte pošiljatelju pred preverjanji dostopa HTTP
Preverjanja pošiljatelja protokola PROXY v Squidu držite ločeno od avtorizacije ciljne domene in zahteve odjemalca.
Uporabite proxy_protocol_access za zaupanje posredniku, ki priskrbi metapodatke, ne za izbiranje dovoljenih spletnih mest. V Squidu 5–7 se preverjanje izvede enkrat po vzpostavitvi TCP na poslušalniku require-proxy-header, preden se obdelajo glave zahteve HTTP:
acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny allZamenjajte primer naslova posrednika in omejite omrežni dostop do tega poslušalnika. Na tej stopnji Squid preveri dejanskega partnerja TCP, preden sprejme priskrbljene metapodatke. Po sprejemu uporabi navedeni naslov odjemalca za nadaljnja preverjanja ACL in beleženje. Zaupanje posredniku na podlagi naslova odjemalca, ki ga navaja, bi ta vrstni red obrnilo.
Ohranite http_access za poznejša dovoljenja za vir odjemalca in cilj. Sprejem metapodatkov ne dovoljuje dostopa do spletnih mest, in ACL ciljne domene ne more odgovoriti na prejšnje vprašanje o zaupanju v pošiljatelja.
Pošiljatelj in prejemnik se morata dogovoriti o podprti različici protokola PROXY. Običajen odjemalec HTTP ne more uporabljati tega poslušalnika z obveznim predpono kot običajno končno točko posrednika. Če sta potrebni obe obliki, uporabite namerno ločene končne točke, namesto da podvajate isti naslov poslušanja in vrata.
Zaupanja vreden posrednik lahko vpliva na avtorizacijo na podlagi naslova prek identitete odjemalca, ki jo priskrbi. To zmožnost dajte samo predvidenemu posredniku.