Squid PROXY-Protokoll: Dem Absender vertrauen, bevor die HTTP-Zugriffsprüfungen greifen

Nutzen Sie proxy_protocol_access, um dem Relay zu vertrauen, das die Metadaten liefert, nicht um erlaubte Websites auszuwählen. In Squid 5–7 läuft die Prüfung einmal nach dem TCP-Aufbau an einem require-proxy-header-Listener und damit vor der Verarbeitung der HTTP-Anfrage-Header:

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

Ersetzen Sie die Beispieladresse des Relays und beschränken Sie den Netzzugriff auf diesen Listener. In dieser Phase prüft Squid den tatsächlichen TCP-Peer, bevor die gelieferten Metadaten akzeptiert werden. Nach der Annahme verwendet es die behauptete Client-Adresse für die folgenden ACL-Prüfungen und für das Logging. Einem Relay auf Basis der von ihm behaupteten Client-Adresse zu vertrauen, würde diese Reihenfolge umkehren.

Behalten Sie http_access für die späteren Berechtigungen zu Client-Quelle und Ziel bei. Die Annahme der Metadaten autorisiert keinen Website-Zugriff, und eine ACL für Ziel-Domains kann die frühere Frage nach dem Absendervertrauen nicht beantworten.

Absender und Empfänger müssen sich auf eine unterstützte Version des PROXY-Protokolls einigen. Ein einfacher HTTP-Client kann diesen Listener mit Pflicht-Präfix nicht als gewöhnlichen Proxy-Endpunkt nutzen. Werden beide Formen gebraucht, verwenden Sie bewusst getrennte Endpunkte, statt dieselbe Listenadresse und denselben Port zu duplizieren.

Ein vertrauenswürdiges Relay kann die adressbasierte Autorisierung über die von ihm gelieferte Client-Identität beeinflussen. Räumen Sie diese Möglichkeit nur der vorgesehenen Zwischenstelle ein.