O rețea doar cu IPv6 rupe VPN-ul înainte de a porni tunelul

Laptopul se conectează la un Wi-Fi de conferință care distribuie doar IPv6, clientul VPN se învârte și eșuează, iar același profil funcționase într-un hotel cu o oră înainte. Nimic nu s-a schimbat în acreditări. Ce s-a schimbat este că acum clientul trebuie să ajungă la o destinație IPv4 printr-o rețea care transportă doar IPv6, și nu toți clienții știu cum să facă asta.

Parcurgeți aceiași cinci pași pe care îi parcurg pachetele.

Pasul 1: observați căutarea numelui

Dacă profilul folosește un nume de gazdă, prima întrebare este ce returnează resolverul. dig AAAA vpn.example.com în rețeaua doar cu IPv6 returnează o înregistrare AAAA reală, una sintetizată de DNS64 sau nimic. Un răspuns sintetizat codează destinația IPv4 într-un prefix de traducere, și abia atunci un client fără destinație IPv6 o poate atinge. Un profil cu o adresă IPv4 codificată fix nu ajunge niciodată aici, pentru că nu există niciun nume de sintetizat.

Acea singură diferență explică majoritatea rapoartelor „merge acolo, eșuează aici”, și e nevoie de o singură comandă ca să o vezi.

Pasul 2: vedeți ce familie a ales clientul

Uitați-vă la socket, nu la bara de progres. Un client care deschide un socket IPv4 către o adresă IPv4 pe o legătură doar cu IPv6 nu are unde să îl trimită, iar eșecul apare ca un timeout, nu ca o eroare de nume. ss -tanp în timp ce clientul se conectează arată adresa de la distanță și familia pe care a încercat-o. Comparați cu ip -6 route pentru a confirma că ruta implicită este un salt IPv6 următor real.

Familia de adrese din tabelul de socketuri este faptul. Bara de progres este un rezumat scris de altcineva.

Pasul 3: separați traducerea de tunel

NAT64 și DNS64 sunt modul în care rețeaua de acces ajunge la destinații IPv4, și nu fac nimic pentru tunel odată ce acesta este ridicat. Un tunel stabilit pe o cale tradusă tot negociază propria adresare internă, iar acoperirea internă IPv4 sau IPv6 este o chestiune de politică separată. Dacă clientul se conectează și apoi nu ajunge nicăieri, ați trecut de traducere și sunteți în rutare, ceea ce este o altă investigație cu alte dovezi.

Eșecul traducerii arată ca o lipsă de conectare. Eșecul acoperirii interne arată ca o conectare fără a ajunge nicăieri.

Pasul 4: testați același profil într-o altă rețea

Duceți același profil, versiunea clientului și acreditările într-o rețea cu stivă dublă și repetați. Dacă acolo funcționează și eșuează pe calea doar cu IPv6, variabila este rețeaua de acces, nu profilul. Notați în tichet versiunea clientului și starea rețelei, pentru că soluția finală este o actualizare a clientului sau o altă destinație.

Un raport care spune că VPN-ul este stricat nu este acționabil. Un raport care spune că eșuează doar la accesul doar cu IPv6 este un raport de eroare.

Pasul 5: reparați calea, nu setările de securitate

Toate reparațiile tentante înrăutățesc lucrurile. Dezactivarea IPv6 elimină singura cale oferită de rețea. Îndreptarea clientului către un resolver public strică sinteza DNS64, pentru că acea sinteză trebuie să vină de la resolverul din spatele traducătorului. Dezactivarea verificării certificatului vă dă o conexiune către ceva ce nu puteți identifica. Niciuna dintre ele nu este o reparație, iar două sunt regresii de securitate care vor supraviețui incidentului.

Opțiunile reale sunt un client care acceptă modelul de traducere de rețea sau o destinație cu o adresă IPv6 accesibilă. Cereți una dintre ele.