Protocolo PROXY do Squid: confie no emissor antes das verificações de acesso HTTP

Use proxy_protocol_access para confiar no relay que fornece os metadados, não para escolher sites permitidos. No Squid 5–7, a verificação é executada uma vez após o estabelecimento do TCP num ouvinte require-proxy-header, antes de os cabeçalhos do pedido HTTP serem processados:

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

Substitua o endereço de relay do exemplo e restrinja o acesso de rede a este ouvinte. Nesta fase, o Squid verifica o par TCP real antes de aceitar os metadados fornecidos. Após a aceitação, usa o endereço de cliente declarado para as verificações ACL e o registo seguintes. Confiar num relay com base no endereço de cliente que ele declara inverteria essa ordem.

Mantenha http_access para as permissões posteriores de origem de cliente e de destino. Aceitar metadados não autoriza o acesso a sites, e uma ACL de domínio de destino não consegue responder à pergunta anterior sobre a confiança no emissor.

O emissor e o recetor têm de acordar uma versão suportada do protocolo PROXY. Um cliente HTTP simples não pode usar este ouvinte com prefixo obrigatório como ponto final de proxy comum. Se forem necessárias ambas as formas, use pontos finais deliberadamente separados em vez de duplicar o mesmo endereço de escuta e porto.

Um relay fidedigno pode influenciar a autorização baseada em endereço através da identidade de cliente que fornece. Conceda essa capacidade apenas ao intermediário previsto.