VPN de doble pila: el client tria la família d'adreces, no tu

El túnel està aixecat, els llocs IPv4 carreguen i un nom d'amfitrió expira. La conclusió immediata és que la VPN està trencada o que les credencials són incorrectes, i normalment no és cert cap de les dues. El nom va retornar una adreça IPv4 i una IPv6, l'aplicació en va triar una, i només un d'aquests candidats tenia un camí funcional. El client va prendre una decisió de selecció; el túnel simplement no cobria el que havia triat.

Triar no és prometre cobertura

La selecció d'adreça per defecte, descrita a l'RFC 6724, decideix quina parella d'origen i destinació prefereix un amfitrió quan n'hi ha diverses de disponibles. Happy Eyeballs hi afegeix una estratègia de connexió: inicia intents a les dues famílies i es queda amb la que respon primer, de manera que l'usuari no espera que una família trencada expiri.

Cap dels dos mecanismes no crea una ruta. Si el teu túnel només transporta IPv4, un candidat AAAA segueix sent una destinació legítima que el client pot provar, i el fracàs es veu com una càrrega lenta i no com un error, perquè el navegador ha retrocedit. L'usuari informa d'un lloc lent, no trencat, i el tiquet de suport hereta aquesta vaguetat. Reproduceix-ho amb una família fixa i l'informe es torna específic.

Aquest retrocés és la raó per la qual el símptoma és inconsistent entre aplicacions. Un navegador amaga el retard; un client de línia d'ordres amb una família fixa et mostra el fracàs real immediatament.

Troba la família que la petició ha utilitzat realment

Comença pel nom, no pel túnel. Consulta els dos tipus de registre i anota què ha tornat:

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

Si la petició v4 té èxit i la v6 falla, has reproduït el problema en una forma que pots depurar. Si totes dues funcionen des de l'intèrpret i el navegador continua fallant, mira el resolutor propi de l'aplicació o una resposta en memòria cau abans de tocar el túnel.

Guarda la família i la destinació a les notes. Un tiquet que diu que el lloc no carrega per la VPN no el pot comprovar ningú, mentre que un tiquet que diu que AAAA falla i A funciona assenyala una ruta concreta.

Comprova la ruta d'aquella família

Per a la família que falla, pregunta al nucli quin camí faria servir i compara'l amb les adreces configurades del túnel. A Linux, ip -6 route get per a la destinació mostra la interfície i l'origen que se seleccionarien.

Després comprova el túnel mateix. Els parells de WireGuard porten una llista d'IP permeses, i una entrada per a 0.0.0.0/0 no diu res sobre IPv6. Si la llista del parell no té cap prefix IPv6, el client no té cap motiu per enviar trànsit AAAA al túnel, i el paquet surt pel que l'amfitrió faria altrament.

Les regles de tallafoc i la política NAT mereixen la mateixa comprovació per família. Una regla escrita per a IPv4 no cobreix IPv6 en cap plataforma, i aquesta és la raó més habitual que una família funcioni i l'altra no.

No desactivis IPv6 per simplificar la captura de pantalla

Desactivar IPv6 a tot el sistema farà desaparèixer el símptoma i et deixarà sense diagnòstic. També trenca qualsevol destinació que sigui només IPv6, i amaga el mateix error per a la propera aplicació. Si una màquina realment no hauria d'usar IPv6, això és una política deliberada amb un propietari i una prova. Desactivar-lo durant un incident no és ni una cosa ni l'altra.

Decideix què ha de fer el client amb la família i configura-ho explícitament: transporta-la pel túnel, o bloqueja-la d'una manera suportada perquè la selecció no ofereixi mai un candidat inabastable. Tots dos són dissenys legítims. Una desactivació global no ho és, perquè no és cap disseny.

Què cal posar al tiquet

Anota quatre coses: el nom d'amfitrió, la família que ha fallat, la ruta que ha triat el nucli i el resultat d'una petició específica de la família. Aquest conjunt és suficient perquè algú altre reprodueixi el fracàs sense endevinar quin dels dos camins volies dir.

Les regles de selecció d'adreces de l'RFC 6724 expliquen per què el client va preferir el candidat que va preferir, i l'RFC 8305 explica el comportament de cursa que va amagar el retard. Cap dels dos no encaminarà cap paquet per tu, i aquesta és la part que ha de fer el túnel.