TAG: tcp_outgoing_address :: permite mapear requisições para diferentes endereços IP com base no nome do usuário ou no endereço de origem do usuário que fez a requisição.


Por exemplo, encaminhamento de clientes com IPs dedicados para certas sub-redes:


Processa os recursos na ordem especificada, parando na primeira linha que corresponder. O Squid irá adicionar uma versão de teste de IP implícito para cada linha:

• Requisições indo para sites IPv4 usarão endereços: 10.1.0.*
• Requisições indo para sites IPv6 usarão endereços: 2001:db8:*

Nota 1: esta opção é incompatível com o uso de clientes que dependem de ACLs em conexões persistentes no lado servidor. Para garantir resultados corretos, é melhor definir "server_persistent_connections" como "off" quando usar esta opção.

Nota 2: esta opção é incompatível para definir um IP local nas conexões TCP de saída usando um TPROXY. Quando precisar, use as opções "no-tproxy", "cache_peer" e "client_dst_passthru" para reabilitar o encaminhamento normal.
Default: none


TAG: host_verify_strict :: independentemente da configuração desta opção, o Squid sempre verifica se o endereço IP de destino corresponde ao domínio do cabeçalho do host ou do IP (chamado "authority form URL").

Isto é feito para satisfazer a exigência da RFC2616, seção 14.23:

"O valor do campo host deve representar a autoridade de nomeação do servidor de origem ou gateway dada pela URL original".

Quando setado em "ON": Squid sempre responde com uma página de erro HTTP 409 (Conflict) e registra um log de segurança. O Squid verifica se o endereço IP de destino corresponde ao cabeçalho do host para o tráfego forward-proxy e reverse-proxy.

Para esse dois tipos de tráfego, o Squid compara os cabeçalhos do host e os componentes Request-URI:

• Os nomes do host (domínio ou IP) devem ser idênticos, mas se estiverem sem valor, todas as verificações serão desabilitadas. Os nomes de host devem ser IP ou FQDN.
• Os números de portas devem ser idênticos, mas se a porta estiver faltando, o esquema padrão é assumido.

Quando setado em OFF (padrão): O Squid permite que as requisições suspeitas continuem, mas registra um aviso de segurança e bloqueia o cache de resposta.

• O tráfego forward-proxy não é verificado em tudo.
• O tráfego reverse-proxy não é verificado em tudo.
• O tráfego interceptado é tratado de acordo com a opção client_dst_passthru.
• Requisições interceptadas nas quais falharam a verificação, são enviadas para o destino original do cliente em vez de DIRECT. Isto substitui "client_dst_passthru off".

Requisições CONNECT suspeitas são sempre respondidas com uma página de erro HTTP 409 (Conflict).

Nota de Segurança: Como descrito em "CVE-2009-0801", quando o "host:header for" usado para determinar o destino de uma requisição, torna-se trivial que scripts maliciosos em sites remotos contornem a política de segurança do navegador e as proteções sandboxing.

A causa disso é que tais applets estão autorizadas a efetuar sua própria pilha TCP, caso em que a política sandboxing do navegador verifica apenas que a applet tenta contatar o mesmo endereço IP a partir de onde foi carregado. O "host:header" pode ser diferente do IP conectado e da origem aprovada na requisição.

Default: host_verify_strict off


TAG: client_dst_passthru :: com NAT ou TPROXY o tráfego pode passar a requisição diretamente ao IP de destino original do cliente ou buscar uma fonte mais rápida usando o cabeçalho do host HTTP.

A utilização do host para localizar servidores alternativos fornecem uma conectividade mais rápida com um leque de opções de recuperação de falhas. Mas também, pode levar a problemas de conectividade quando o cliente e o servidor estão tentando interações stateful desconhecidas para o proxy.

Esta opção (on por padrão) impede que DNSs alternativos sejam localizados para enviar o tráfego direto a um servidor de origem. O IP de destino e a porta originais dos clientes serão usados em vez dos desconhecidos.

Independentemente desta opção estar configurada, o Squid verificará o "host:header" e todo o tráfego será tratado como se esta opção estivesse ON.

Veja "host_verify_strict" para obter detalhes do processo de verificação.
Default: client_dst_passthru on