Síť pouze s IPv6 rozbije VPN dřív, než se tunel spustí

Notebook se připojí ke konferenční Wi-Fi, která rozdává jen IPv6, klient VPN se točí a selže, a tentýž profil před hodinou fungoval v hotelu. Na přihlašovacích údajích se nic nezměnilo. Změnilo se to, že klient teď musí dosáhnout destinace IPv4 přes síť, která nese jen IPv6, a ne každý klient to umí.

Projděte stejných pět kroků, kterými procházejí pakety.

Krok 1: sledujte vyhledání jména

Pokud profil používá jméno hostitele, první otázka je, co vrací resolver. dig AAAA vpn.example.com v síti pouze s IPv6 vrací skutečný záznam AAAA, syntetizovaný záznam z DNS64, nebo nic. Syntetizovaná odpověď kóduje destinaci IPv4 uvnitř překladového prefixu, a teprve pak se k ní klient bez destinace IPv6 dostane. Profil s pevně zadanou adresou IPv4 se sem nikdy nedostane, protože není žádné jméno k syntéze.

Ten jediný rozdíl vysvětluje většinu hlášení „tam to funguje, tady ne“, a k jeho spatření stačí jeden příkaz.

Krok 2: podívejte se, kterou rodinu klient vytočil

Sledujte socket, ne ukazatel průběhu. Klient, který na lince pouze s IPv6 otevře socket IPv4 na adresu IPv4, nemá kam ho poslat, a selhání se projeví jako časový limit, ne jako chyba jména. ss -tanp během připojování klienta ukáže vzdálenou adresu a rodinu, kterou zkusil. Porovnejte to s ip -6 route, abyste potvrdili, že výchozí cesta je skutečný další skok IPv6.

Rodina adres v tabulce socketů je fakt. Ukazatel průběhu je shrnutí, které napsal někdo jiný.

Krok 3: oddělte překlad od tunelu

NAT64 a DNS64 jsou způsob, jakým přístupová síť dosahuje destinací IPv4, a pro tunel po jeho vybudování nedělají nic. Tunel zřízený přes překládanou cestu si stále vyjednává vlastní vnitřní adresování a vnitřní pokrytí IPv4 nebo IPv6 je samostatná otázka politiky. Pokud se klient připojí a pak na nic nedosáhne, jste za překladem a v směrování, což je jiné vyšetřování s jinými důkazy.

Selhání překladu vypadá jako nikdy se nepřipojit. Selhání vnitřního pokrytí vypadá jako připojit se a na nic nedosáhnout.

Krok 4: otestujte stejný profil v jiné síti

Vezměte stejný profil, verzi klienta a přihlašovací údaje do sítě s duálním stackem a opakujte. Pokud tam funguje a na cestě pouze s IPv6 selhává, proměnnou je přístupová síť, ne profil. Zapište do tiketu verzi klienta a stav sítě, protože konečnou opravou je aktualizace klienta nebo jiná destinace.

Hlášení, že VPN je rozbitá, je nepoužitelné. Hlášení, že selhává jen při přístupu pouze s IPv6, je hlášení chyby.

Krok 5: opravte cestu, ne nastavení zabezpečení

Lákavé opravy všechno zhoršují. Vypnutí IPv6 odstraní jedinou cestu, kterou síť nabízí. Nasměrování klienta na veřejný resolver rozbije syntézu DNS64, protože ta musí přicházet z resolveru za překladačem. Vypnutí ověřování certifikátů vám dá spojení s něčím, co nedokážete identifikovat. Nic z toho není oprava a dvě z toho jsou bezpečnostní regrese, které incident přežijí.

Skutečné možnosti jsou klient, který podporuje model síťového překladu, nebo destinace s dosažitelnou adresou IPv6. Požádejte o jedno z toho.