Una xarxa només IPv6 trenca la VPN abans que arrenqui el túnel

L’ordinador portàtil s’uneix a un Wi-Fi de congrés que només reparteix IPv6, el client VPN gira i falla, i el mateix perfil havia funcionat en un hotel una hora abans. No ha canviat res de les credencials. El que ha canviat és que ara el client ha d’arribar a una destinació IPv4 a través d’una xarxa que només porta IPv6, i no tots els clients saben com fer-ho.

Seguiu els mateixos cinc passos que fan els paquets.

Pas 1: observeu la consulta de nom

Si el perfil fa servir un nom d’amfitrió, la primera pregunta és què retorna el resolutor. dig AAAA vpn.example.com a la xarxa només IPv6 retorna un registre AAAA real, un de sintetitzat per DNS64 o res de res. Una resposta sintetitzada codifica la destinació IPv4 dins d’un prefix de traducció, i només llavors un client sense destinació IPv6 hi pot arribar. Un perfil amb una adreça IPv4 fixada no arriba mai fins aquí, perquè no hi ha cap nom per sintetitzar.

Aquesta única diferència explica la majoria d’informes «allà funciona, aquí falla», i cal una sola ordre per veure-ho.

Pas 2: mireu quina família ha marcat el client

Mireu el sòcol en lloc de la barra de progrés. Un client que obre un sòcol IPv4 cap a una adreça IPv4 en un enllaç només IPv6 no té on enviar-lo, i la fallada apareix com a temps d’espera i no com a error de nom. ss -tanp mentre el client es connecta mostra l’adreça remota i la família que ha provat. Compareu-ho amb ip -6 route per confirmar que la ruta per defecte és un salt IPv6 real.

La família d’adreces de la taula de sòcols és el fet. La barra de progrés és un resum que ha escrit una altra persona.

Pas 3: separeu la traducció del túnel

NAT64 i DNS64 són com la xarxa d’accés arriba a destinacions IPv4, i no fan res pel túnel un cop està aixecat. Un túnel establert per un camí traduït encara negocia el seu propi adreçament interior, i la cobertura interior IPv4 o IPv6 és una qüestió de política a part. Si el client es connecta i després no arriba a res, ja heu passat la traducció i sou a l’encaminament, que és una altra investigació amb altres proves.

La fallada de la traducció sembla no connectar mai. La fallada de la cobertura interior sembla connectar i no arribar a res.

Pas 4: proveu el mateix perfil en una altra xarxa

Porteu el mateix perfil, versió de client i credencials a una xarxa de doble pila i repetiu. Si allà funciona i falla al camí només IPv6, la variable és la xarxa d’accés i no el perfil. Anoteu la versió del client i l’estat de la xarxa al tiquet, perquè la solució final és una actualització del client o una altra destinació.

Un informe que diu que la VPN està trencada no és accionable. Un informe que diu que falla només en accés només IPv6 és un informe d’error.

Pas 5: arregleu el camí, no la configuració de seguretat

Totes les reparacions temptadores empitjoren les coses. Desactivar IPv6 elimina l’únic camí que ofereix la xarxa. Apuntar el client a un resolutor públic trenca la síntesi DNS64, perquè aquesta síntesi ha de venir del resolutor que hi ha darrere del traductor. Desactivar la verificació de certificats us dona una connexió amb una cosa que no podeu identificar. Cap d’aquestes és una reparació, i dues són regressions de seguretat que sobreviuran a l’incident.

Les opcions reals són un client que admeti el model de traducció de xarxa o una destinació amb una adreça IPv6 abastable. Demaneu una de les dues.