É possível aceitar um cliente por IPv4 e alcançar o site solicitado por IPv6. São conexões separadas. Uma política do lado do site não deve rejeitar automaticamente clientes IPv4.

Essa é a armadilha em exemplos que combinam uma negação de família de destino com src ipv4: a ACL de origem muda quem pode se conectar, não apenas quais conexões de site são permitidas.

Defina a restrição pretendida

Para versões do Squid que suportam as ACLs IP relevantes, uma regra de família de destino pode usar dst ipv4 para identificar destinos IPv4. Integre essas regras à autenticação e às permissões de destino existentes; não acrescente uma permissão ampla de IPv6 que as contorne.

A referência de ACL distingue tipos de origem e de destino. Isto é uma restrição, não um serviço de tradução automática. Um site apenas IPv4 pode ficar inacessível ainda que a máquina pudesse alcançá-lo por IPv4.

Vincular um endereço IPv6 de saída também não é toda a política de aplicação. A seleção de origem, as famílias de destino permitidas, as respostas DNS e a acessibilidade real da rede contribuem. Decida explicitamente se o retorno a IPv4 é aceitável.

Alterar forwarded_for não resolve este problema. Isso afeta um cabeçalho HTTP, não a família de endereços da conexão TCP do proxy. Da mesma forma, um resolvedor DNS IPv6 não garante que todo nome que responde tenha um destino IPv6.

Verifique o comportamento específico da versão antes de adotar uma grande configuração antiga. Em particular: dns_v4_first não é um comutador de preferência de família suportado no Squid 5 a 7. Uma política que você pode descrever com precisão é mais fácil de validar do que um conjunto de ajustes IPv6 não relacionados.

Artigos relacionados