Clientes Squid IPv4 e destinos IPv6: políticas separadas
Un cliente IPv4 pode usar Squid para chegar a un sitio web IPv6. Distinga as restricións de destino, as ACL de orixe e a selección de enderezo antes de escoller unha política só IPv6.
É posible aceptar un cliente por IPv4 e chegar ao seu sitio web solicitado por IPv6. Son conexións separadas. Unha política sobre o lado do sitio web non debería rexeitar automaticamente os clientes IPv4.
Esa é a trampa en exemplos que combinan unha denegación de familia de destino con src ipv4: a ACL de orixe cambia quen pode conectarse, non só que conexións a sitios web se permiten.
Defina a restrición prevista
Para as versións de Squid que admiten as ACL IP correspondentes, unha regra de familia de destino pode usar dst ipv4 para identificar destinos IPv4. Integre estas regras coa autenticación e os permisos de destino existentes; non engada un permiso amplo de IPv6 que as eluda.
A referencia de ACL distingue os tipos de orixe e destino. Isto é unha restrición, non un servizo de tradución automática. Un sitio web só IPv4 pode quedar inaccesible aínda que a máquina puidese chegar a el por IPv4.
Vincular un enderezo IPv6 de saída tampouco é toda a política de aplicación. A selección de orixe, as familias de destino permitidas, as respostas DNS e a alcanzabilidade real da rede contribúen. Decida explicitamente se o retorno a IPv4 é aceptable.
Cambiar forwarded_for non resolve este problema. Afecta unha cabeceira HTTP, non a familia de enderezos da conexión TCP do proxy. Do mesmo xeito, un resolutor DNS IPv6 non garante que todos os nomes que responde teñan destino IPv6.
Comprobe o comportamento específico da versión antes de adoptar unha configuración antiga grande. En particular: dns_v4_first non é un conmutador de preferencia de familia admitido en Squid 5 a 7. Unha política que pode describir con precisión é máis fácil de validar que un conxunto de axustes IPv6 non relacionados.