Eit nettverk med berre IPv6 bryt VPN-en før tunnelen startar

Laptopen koplar seg til eit konferanse-Wi-Fi som berre deler ut IPv6, VPN-klienten snurrar og feilar, og same profil fungerte på eit hotell ein time tidlegare. Ingenting i påloggingsinformasjonen er endra. Det som er endra, er at klienten no må nå eit IPv4-mål gjennom eit nettverk som berre ber IPv6, og ikkje alle klientar veit korleis dei skal gjere det.

Gå dei same fem trinna som pakkane går.

Trinn 1: sjå på namneoppslaget

Viss profilen brukar eit vertsnamn, er det første spørsmålet kva resolveren returnerer. dig AAAA vpn.example.com på nettverket med berre IPv6 returnerer ein ekte AAAA-post, ein syntetisert frå DNS64 eller ingenting i det heile. Eit syntetisert svar kodar IPv4-målet inne i eit omsetjingsprefiks, og først då kan ein klient utan IPv6-mål nå det. Ein profil med ein hardkoda IPv4-adresse kjem aldri så langt, fordi det ikkje er noko namn å syntetisere.

Den eine skilnaden forklarar dei fleste «verkar der, feilar her»-rapportane, og det krevst éin kommando for å sjå det.

Trinn 2: sjå kva familie klienten kalla på

Sjå på socketen i staden for framdriftslinja. Ein klient som opnar ein IPv4-socket til ein IPv4-adresse på ei lenkje med berre IPv6, har ingen stad å sende han, og feilen viser seg som ein tidsavbrot i staden for ein namnefeil. ss -tanp medan klienten koplar til viser fjernadressa og familien han prøvde. Samanlikn det med ip -6 route for å stadfeste at standardruta er eit ekte IPv6-nestehopp.

Adressefamilien i socket-tabellen er faktumet. Framdriftslinja er eit samandrag som nokon andre har skrive.

Trinn 3: skil omsetjinga frå tunnelen

NAT64 og DNS64 er måten tilgangsnettverket når IPv4-mål på, og dei gjer ingenting for tunnelen når han først er oppe. Ein tunnel sett opp over ein omsett veg, forhandlar framleis om si eiga interne adressering, og den interne IPv4- eller IPv6-dekninga er eit eige policyspørsmål. Viss klienten koplar til og deretter ikkje når noko, er du forbi omsetjinga og inne i rutinga, som er ei anna undersøking med andre prov.

Omsetjing som feilar ser ut som at ein aldri koplar til. Intern dekning som feilar ser ut som at ein koplar til og ikkje når noko.

Trinn 4: test den same profilen på eit anna nettverk

Ta med den same profilen, klientversjonen og påloggingsinformasjonen til eit dobbeltstakka nettverk og gjer det om att. Viss det verkar der og feilar på vegen med berre IPv6, er variabelen tilgangsnettverket og ikkje profilen. Noter klientversjonen og nettverkstilstanden i saka, fordi den endelege løysinga er ein klientoppdatering eller eit anna mål.

Ein rapport som seier at VPN-en er øydelagd, er ikkje handlingsbar. Ein rapport som seier at han berre feilar på tilgang med berre IPv6, er ein feilrapport.

Trinn 5: reparer vegen, ikkje tryggingsinnstillingane

Dei freistande reparasjonane gjer alt verre. Å slå av IPv6 fjernar den einaste vegen nettverket tilbyr. Å peike klienten mot ein offentleg resolver øydelegg DNS64-syntesen, fordi den syntesen må kome frå resolveren bak omsetjaren. Å slå av sertifikatverifisering gjev deg ei tilkopling til noko du ikkje kan identifisere. Ingen av dei er ein reparasjon, og to av dei er tryggingsregresjonar som vil overleve hendinga.

Dei reelle alternativa er ein klient som støttar nettverksomsetjingsmodellen, eller eit mål med ei tilgjengeleg IPv6-adresse. Be om eitt av dei.