És possible acceptar un client per IPv4 i arribar al lloc web sol·licitat per IPv6. Són connexions separades. Una política sobre el costat del lloc web no hauria de rebutjar automàticament els clients IPv4.

Aquesta és la trampa en exemples que combinen una denegació de família de destinació amb src ipv4: l'ACL d'origen canvia qui pot connectar-se, no només quines connexions a llocs web es permeten.

Definiu la restricció prevista

Per a les versions de Squid que admeten les ACL IP corresponents, una regla de família de destinació pot utilitzar dst ipv4 per identificar destinacions IPv4. Integreu aquestes regles amb l'autenticació i els permisos de destinació existents; no afegiu una permissió àmplia d'IPv6 que les ometi.

La referència d'ACL distingeix els tipus d'origen i de destinació. Això és una restricció, no un servei de traducció automàtica. Un lloc web només IPv4 pot quedar inaccessible encara que la màquina hi pogués arribar per IPv4.

Vincular una adreça IPv6 de sortida tampoc no és tota la política d'aplicació. La selecció d'origen, les famílies de destinació permeses, les respostes DNS i l'abastabilitat real de la xarxa hi contribueixen. Decidiu explícitament si el retorn a IPv4 és acceptable.

Canviar forwarded_for no resol aquest problema. Afecta una capçalera HTTP, no la família d'adreces de la connexió TCP del proxy. Igualment, un resolutor DNS IPv6 no garanteix que tots els noms que respon tinguin destinació IPv6.

Comproveu el comportament específic de la versió abans d'adoptar una configuració antiga gran. En particular: dns_v4_first no és un commutador de preferència de família admès a Squid 5 fins a 7. Una política que podeu descriure amb precisió és més fàcil de validar que un conjunt de paràmetres IPv6 no relacionats.

Articles relacionats