Protocolo PROXY de Squid: confíe en el emisor antes de las comprobaciones de acceso HTTP

Use proxy_protocol_access para confiar en el relay que aporta los metadatos, no para elegir sitios web permitidos. En Squid 5–7, la comprobación se ejecuta una vez tras el establecimiento de TCP en un oyente require-proxy-header, antes de procesar las cabeceras de la solicitud 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

Sustituya la dirección de relay del ejemplo y restrinja el acceso de red a este oyente. En esta etapa, Squid comprueba el par TCP real antes de aceptar los metadatos facilitados. Tras la aceptación, usa la dirección de cliente afirmada para las comprobaciones ACL y el registro posteriores. Confiar en un relay basándose en la dirección de cliente que afirma invertiría ese orden.

Reserve http_access para los permisos posteriores de origen de cliente y de destino. Aceptar metadatos no autoriza el acceso a sitios web, y una ACL de dominio de destino no puede responder a la pregunta anterior sobre la confianza en el emisor.

El emisor y el receptor deben acordar una versión compatible del protocolo PROXY. Un cliente HTTP simple no puede usar este oyente con prefijo obligatorio como punto final de proxy ordinario. Si se necesitan ambas formas, use puntos final deliberadamente separados en lugar de duplicar la misma dirección de escucha y el mismo puerto.

Un relay de confianza puede influir en la autorización basada en direcciones mediante la identidad de cliente que aporta. Conceda esa capacidad solo al intermediario previsto.