Et netværk med kun IPv6 bryder VPN’en, før tunnelen starter

Laptoppen logger på et konference-Wi-Fi, der kun uddeler IPv6, VPN-klienten snurrer og fejler, og den samme profil virkede på et hotel en time tidligere. Der er ikke ændret noget i legitimationsoplysningerne. Det, der er ændret, er, at klienten nu skal nå en IPv4-destination gennem et netværk, der kun bærer IPv6, og ikke alle klienter ved, hvordan man gør det.

Gå de samme fem trin, som pakkerne går.

Trin 1: se på navneopslaget

Hvis profilen bruger et værtsnavn, er det første spørgsmål, hvad resolveren returnerer. dig AAAA vpn.example.com på netværket med kun IPv6 returnerer en rigtig AAAA-post, en syntetiseret fra DNS64 eller slet intet. Et syntetiseret svar indkoder IPv4-destinationen inde i et oversættelsespræfiks, og først da kan en klient uden IPv6-destination nå den. En profil med en hårdkodet IPv4-adresse når aldrig hertil, fordi der ikke er noget navn at syntetisere.

Den ene forskel forklarer de fleste »virker der, fejler her«-rapporter, og der skal én kommando til at se det.

Trin 2: se, hvilken familie klienten kaldte på

Se på socket’en i stedet for statuslinjen. En klient, der åbner en IPv4-socket til en IPv4-adresse på et link med kun IPv6, har ingen steder at sende den, og fejlen viser sig som en timeout i stedet for en navnefejl. ss -tanp, mens klienten forbinder, viser fjernadressen og den familie, den forsøgte. Sammenlign det med ip -6 route for at bekræfte, at standarden er et rigtigt IPv6-næstehop.

Adressefamilien i socket-tabellen er kendsgerningen. Statuslinjen er et resumé, som en anden har skrevet.

Trin 3: adskil oversættelse fra tunnelen

NAT64 og DNS64 er måden, adgangsnetværket når IPv4-destinationer på, og de gør intet for tunnelen, når den først er oppe. En tunnel, der er oprettet over en oversat vej, forhandler stadig sin egen interne adressering, og den interne IPv4- eller IPv6-dækning er et separat politikspørgsmål. Hvis klienten forbinder og derefter ikke når noget, er du forbi oversættelsen og inde i routing, hvilket er en anden undersøgelse med andre beviser.

Oversættelse, der fejler, ser ud som om man aldrig forbinder. Intern dækning, der fejler, ser ud som om man forbinder og ikke når noget.

Trin 4: test den samme profil på et andet netværk

Tag den samme profil, klientversion og legitimationsoplysninger med til et dobbeltstak-netværk og gentag. Hvis det virker der og fejler på vejen med kun IPv6, er variablen adgangsnetværket og ikke profilen. Notér klientversionen og netværkstilstanden i sagen, fordi den endelige løsning er en klientopdatering eller en anden destination.

En rapport, der siger, at VPN’en er i stykker, er ubrugelig. En rapport, der siger, at den kun fejler på adgang med kun IPv6, er en fejlrapport.

Trin 5: ret vejen, ikke sikkerhedsindstillingerne

De fristende reparationer gør alle tingene værre. At slå IPv6 fra fjerner den eneste vej, netværket tilbyder. At pege klienten mod en offentlig resolver bryder DNS64-syntesen, fordi den syntese skal komme fra resolveren bag oversætteren. At slå certifikatverifikation fra giver dig en forbindelse til noget, du ikke kan identificere. Ingen af dem er en reparation, og to af dem er sikkerhedsregressioner, der vil overleve hændelsen.

De reelle muligheder er en klient, der understøtter netværksoversættelsesmodellen, eller en destination med en tilgængelig IPv6-adresse. Bed om en af dem.