Squid PROXY-protocol: vertrouw de afzender vóór de HTTP-toegangscontroles

Gebruik proxy_protocol_access om de relay te vertrouwen die de metadata levert, niet om toegestane websites te kiezen. In Squid 5–7 draait de controle één keer na de TCP-opzet op een require-proxy-header-listener, voordat de HTTP-verzoekheaders worden verwerkt:

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 het voorbeeldrelayadres en beperk de netwerktoegang tot deze listener. In deze fase controleert Squid de werkelijke TCP-peer voordat de aangeleverde metadata worden geaccepteerd. Na acceptatie gebruikt het het beweerde clientadres voor de latere ACL-controles en voor logging. Een relay vertrouwen op basis van het clientadres dat het beweert, zou die volgorde omdraaien.

Bewaar http_access voor de latere rechten op clientbron en bestemming. Het accepteren van metadata machtigt geen websitetoegang, en een ACL voor doeldomeinen kan de eerdere vraag naar afzendervetrouwen niet beantwoorden.

Afzender en ontvanger moeten het eens worden over een ondersteunde versie van het PROXY-protocol. Een gewone HTTP-client kan deze listener met verplicht voorvoegsel niet als gewoon proxy-eindpunt gebruiken. Zijn beide vormen nodig, gebruik dan bewust gescheiden eindpunten in plaats van hetzelfde luisteradres en dezelfde poort te dupliceren.

Een vertrouwde relay kan adresgebaseerde autorisatie beïnvloeden via de clientidentiteit die hij levert. Geef die mogelijkheid alleen aan de bedoelde tussenpartij.