VPN de dobre pila: o cliente escolle a familia de enderezos, non vostede

O túnel está levantado, os sitios IPv4 cargan e un nome de host esgota o tempo. A conclusión inmediata é que a VPN está rota ou que as credenciais son incorrectas, e normalmente ningunha das dúas cousas é certa. O nome devolveu un enderezo IPv4 e un IPv6, a aplicación escolleu un, e só un deses candidatos tiña un camiño funcional. O cliente tomou unha decisión de selección; o túnel simplemente non cubría o que elixira.

Escoller non é prometer cobertura

A selección de enderezo predeterminada, descrita no RFC 6724, decide que par de orixe e destino prefire un host cando hai varios dispoñibles. Happy Eyeballs engade unha estratexia de conexión por riba: inicia intentos nas dúas familias e queda coa que responde primeiro, para que o usuario non espere a que unha familia rota esgote o tempo.

Ningún dos dous mecanismos crea unha ruta. Se o seu túnel só transporta IPv4, un candidato AAAA segue sendo un destino lexítimo que o cliente pode probar, e o fallo maniféstase como unha carga lenta e non como un erro, porque o navegador retrocedeu. O usuario informa dun sitio lento, non roto, e o ticket de soporte herda esa vaguidade. Reproduza o caso cunha familia fixa e o informe vólvese concreto.

Ese retroceso é a razón de que o síntoma sexa inconsistente entre aplicacións. Un navegador oculta o atraso; un cliente de liña de ordes cunha familia fixa amósalle o fallo real de inmediato.

Averigüe que familia usou realmente a petición

Comece polo nome, non polo túnel. Consulte ambos os tipos de rexistro e anote que volveu:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Se a petición v4 ten éxito e a v6 falla, reproduciu o problema nunha forma que pode depurar. Se ambas funcionan desde a consola e o navegador segue fallando, mire o resolvedor propio da aplicación ou unha resposta en caché antes de tocar o túnel.

Garde a familia e o destino nas súas notas. Un ticket que di que o sitio non carga pola VPN non o pode comprobar ninguén, mentres que un ticket que di que AAAA falla e A funciona apunta a unha ruta concreta.

Comprobe a ruta desa familia

Para a familia que falla, pregunte ao núcleo que camiño usaría e compáreo cos enderezos configurados do túnel. En Linux, ip -6 route get para o destino mostra a interface e a orixe que se seleccionarían.

Despois comprobe o propio túnel. Os pares de WireGuard levan unha lista de IP permitidas, e unha entrada para 0.0.0.0/0 non di nada sobre IPv6. Se a lista do par non ten ningún prefixo IPv6, o cliente non ten motivo para enviar tráfico AAAA ao túnel, e o paquete sae polo que o host faría doutro xeito.

As regras de cortafogos e a política NAT merecen a mesma comprobación por familia. Unha regra escrita para IPv4 non cobre IPv6 en ningunha plataforma, e é a razón máis habitual de que unha familia funcione e a outra non.

Non desactive IPv6 para simplificar a captura de pantalla

Desactivar IPv6 en todo o sistema fará desaparecer o síntoma e deixarao sen diagnóstico. Tamén rompe calquera destino que sexa só IPv6, e esconde o mesmo fallo para a seguinte aplicación. Se unha máquina realmente non debería usar IPv6, iso é unha política deliberada cun propietario e unha proba. Desactivalo durante un incidente non é nin unha cousa nin a outra.

Decida que debe facer o cliente coa familia e confígúeo explicitamente: lévea polo túnel, ou bloquéee dun xeito admitido para que a selección nunca ofreza un candidato inalcanzable. Ambos son deseños lexítimos. Unha desactivación global non é ningún dos dous, porque non é un deseño en absoluto.

Que pór no ticket

Anote catro cousas: o nome de host, a familia que fallou, a ruta que escolleu o núcleo e o resultado dunha petición específica da familia. Ese conxunto abonda para que outra persoa reproduza o fallo sen adiviñar cal dos dous camiños quería dicir.

As regras de selección de enderezos do RFC 6724 explican por que o cliente preferiu o candidato que preferiu, e o RFC 8305 explica o comportamento de carreira que ocultou o atraso. Ningunha das dúas encamiñará un paquete por vostede, e esa é a parte que o túnel ten que facer.