Protocole PROXY de Squid : faire confiance à l'émetteur avant les contrôles d'accès HTTP

Utilisez proxy_protocol_access pour faire confiance au relais qui fournit les métadonnées, non pour choisir les sites web autorisés. Dans Squid 5–7, le contrôle s'exécute une seule fois après l'établissement de TCP sur un écouteur require-proxy-header, avant le traitement des en-têtes de requête 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 all

Remplacez l'adresse de relais de l'exemple et limitez l'accès réseau à cet écouteur. À ce stade, Squid vérifie le pair TCP réel avant d'accepter les métadonnées fournies. Après acceptation, il utilise l'adresse client affirmée pour les contrôles ACL et la journalisation ultérieurs. Faire confiance à un relais d'après l'adresse client qu'il revendique inverserait cet ordre.

Réservez http_access aux autorisations ultérieures de source client et de destination. Accepter des métadonnées n'autorise pas l'accès aux sites web, et une ACL de domaine de destination ne peut pas répondre à la question antérieure sur la confiance envers l'émetteur.

L'émetteur et le récepteur doivent s'accorder sur une version prise en charge du protocole PROXY. Un client HTTP ordinaire ne peut pas utiliser cet écouteur à préfixe obligatoire comme point de terminaison proxy normal. Si les deux formes sont nécessaires, utilisez délibérément des points de terminaison distincts plutôt que de dupliquer la même adresse d'écoute et le même port.

Un relais de confiance peut influencer l'autorisation fondée sur l'adresse par l'identité client qu'il fournit. N'accordez cette capacité qu'à l'intermédiaire prévu.