Squid PROXY-protokol: Vertrou die sender voordat HTTP-toegangscontroles plaasvind

Gebruik proxy_protocol_access om die aflos wat metadata verskaf te vertrou, nie om toegelate webwerwe te kies nie. In Squid 5–7 word die kontrole een keer na TCP-opstelling op 'n require-proxy-header-luisteraar uitgevoer, voordat HTTP-versoekopskrifte verwerk word:

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 all

Vervang die voorbeeld-aflosadres en beperk netwerktoegang tot hierdie luisteraar. Op hierdie stadium kontroleer Squid die werklike TCP-eweknie voordat die verskafde metadata aanvaar word. Ná aanvaarding gebruik dit die beweerde kliëntadres vir die daaropvolgende ACL-kontroles en vir logboeke. Om 'n aflos te vertrou op grond van die kliëntadres wat dit beweer, sou daardie volgorde omkeer.

Hou http_access vir die later regte op kliëntbron en bestemming. Die aanvaarding van metadata magtig nie toegang tot webwerwe nie, en 'n ACL vir die bestemmingsdomein kan nie die vroeëre vraag oor sendervertroue beantwoord nie.

Sender en ontvanger moet oor 'n ondersteunde weergawe van die PROXY-protokol ooreenkom. 'n Gewone HTTP-kliënt kan nie hierdie luisteraar met verpligte voorvoegsel as 'n gewone instaanbediener-eindpunt gebruik nie. As albei vorms nodig is, gebruik doelbewus aparte eindpunte eerder as om dieselfde luisteradres en poort te dupliseer.

'n Vertroude aflos kan adresgebaseerde magtiging beïnvloed deur die kliëntidentiteit wat dit verskaf. Verleen daardie vermoë slegs aan die beoogde tussenganger.