Unha rede só IPv6 rompe a VPN antes de que arrinque o túnel

O portátil conéctase a un Wi-Fi de congreso que só reparte IPv6, o cliente VPN xira e falla, e o mesmo perfil funcionara nun hotel unha hora antes. Nada cambiou nas credenciais. O que cambiou é que agora o cliente debe chegar a un destino IPv4 a través dunha rede que só transporta IPv6, e non todos os clientes saben como facelo.

Percorra os mesmos cinco pasos que percorren os paquetes.

Paso 1: observe a consulta de nome

Se o perfil usa un nome de host, a primeira pregunta é que devolve o resolutor. dig AAAA vpn.example.com na rede só IPv6 devolve un rexistro AAAA real, un sintetizado por DNS64 ou nada de nada. Unha resposta sintetizada codifica o destino IPv4 dentro dun prefixo de tradución, e só entón un cliente sen destino IPv6 pode alcanzalo. Un perfil cun enderezo IPv4 fixado nunca chega ata aquí, porque non hai ningún nome que sintetizar.

Esa única diferenza explica a maioría dos informes «alí funciona, aquí falla», e fai falta un só comando para velo.

Paso 2: mire que familia marcou o cliente

Mire o socket en lugar da barra de progreso. Un cliente que abre un socket IPv4 cara a un enderezo IPv4 nunha ligazón só IPv6 non ten onde envialo, e o fallo aparece como un tempo de espera en vez dun erro de nome. ss -tanp mentres o cliente se conecta mostra o enderezo remoto e a familia que tentou. Compáreo con ip -6 route para confirmar que a ruta por defecto é un salto IPv6 real.

A familia de enderezos na táboa de sockets é o feito. A barra de progreso é un resumo que escribiu outra persoa.

Paso 3: separe a tradución do túnel

NAT64 e DNS64 son como a rede de acceso chega a destinos IPv4, e non fan nada polo túnel unha vez levantado. Un túnel establecido sobre unha ruta traducida segue negociando o seu propio direccionamento interior, e a cobertura interior IPv4 ou IPv6 é unha cuestión de política aparte. Se o cliente se conecta e logo non chega a nada, xa pasou a tradución e está no enrutamento, que é outra investigación con outras probas.

O fallo da tradución parece non conectar nunca. O fallo da cobertura interior parece conectar e non chegar a nada.

Paso 4: probe o mesmo perfil noutra rede

Leve o mesmo perfil, versión de cliente e credenciais a unha rede de dobre pila e repita. Se alí funciona e falla na ruta só IPv6, a variable é a rede de acceso e non o perfil. Anote a versión do cliente e o estado da rede no ticket, porque a solución final é unha actualización do cliente ou outro destino.

Un informe que di que a VPN está rota non é accionable. Un informe que di que falla só en acceso só IPv6 é un informe de erro.

Paso 5: arranxe a ruta, non a configuración de seguridade

Todas as reparacións tentadoras empeoran as cousas. Desactivar IPv6 elimina a única ruta que ofrece a rede. Apuntar o cliente a un resolutor público rompe a síntese DNS64, porque esa síntese ten que vir do resolutor que está detrás do tradutor. Desactivar a verificación de certificados dálle unha conexión con algo que non pode identificar. Ningunha delas é unha reparación, e dúas son regresións de seguridade que sobrevivirán ao incidente.

As opcións reais son un cliente que admita o modelo de tradución de rede ou un destino cun enderezo IPv6 accesible. Pida unha das dúas.