A csak IPv6-os hálózat még az alagút indulása előtt elrontja a VPN-t

A laptop egy konferencia Wi-Fi-jéhez csatlakozik, amely csak IPv6-ot oszt, a VPN-kliens pörög és meghibásodik, pedig ugyanaz a profil egy órával korábban működött egy szállodában. A hitelesítő adatokban semmi sem változott. Az változott meg, hogy a kliensnek most egy IPv4-célt kell elérnie egy csak IPv6-ot szállító hálózaton keresztül, és nem minden kliens tudja, hogyan kell ezt tenni.

Járja be ugyanazt az öt lépést, amelyet a csomagok bejárnak.

1. lépés: figyelje a névfeloldást

Ha a profil gazdagépnevet használ, az első kérdés az, mit ad vissza a feloldó. A dig AAAA vpn.example.com a csak IPv6-os hálózaton valódi AAAA-rekordot, DNS64-ből szintetizált rekordot vagy semmit sem ad vissza. A szintetizált válasz a fordítási előtagban kódolja az IPv4-célt, és csak ezután érheti el azt egy IPv6-cél nélküli kliens. A keményen kódolt IPv4-címmel rendelkező profil soha nem jut el idáig, mert nincs mit szintetizálni.

Ez az egyetlen különbség magyarázza a legtöbb „ott működik, itt meghibásodik” jelentést, és egyetlen parancs elég meglátásához.

2. lépés: nézze meg, melyik családot hívta a kliens

A socketet figyelje, ne a folyamatjelzőt. Az a kliens, amely csak IPv6-os kapcsolaton IPv4-címre nyit IPv4-socketet, nem tudja hova küldeni, és a hiba névhiba helyett időtúllépésként jelenik meg. A ss -tanp a kliens csatlakozása közben megmutatja a távoli címet és a megkísérelt családot. Hasonlítsa össze a ip -6 route kimenetével, hogy megerősítse: az alapértelmezett útvonal valódi IPv6-következő ugrás.

A socket-táblában szereplő címcsalád a tény. A folyamatjelző egy összefoglaló, amelyet valaki más írt.

3. lépés: válassza külön a fordítást az alagúttól

A NAT64 és a DNS64 az, ahogyan a hozzáférési hálózat eléri az IPv4-célokat, és semmit sem tesznek az alagútért, miután az felállt. A lefordított úton létrehozott alagút továbbra is saját belső címzéséről tárgyal, és a belső IPv4- vagy IPv6-lefedettség külön szakpolitikai kérdés. Ha a kliens csatlakozik, majd semmit sem ér el, már túl van a fordításen és az útválasztásban, ami más bizonyítékokkal járó más vizsgálat.

A fordítás meghibásodása úgy néz ki, mint soha nem csatlakozás. A belső lefedettség meghibásodása úgy néz ki, mint csatlakozás és semmi elérése.

4. lépés: tesztelje ugyanazt a profilt egy másik hálózaton

Vigye ugyanazt a profilt, kliensverziót és hitelesítő adatokat egy kettős stack hálózatra, és ismételje meg. Ha ott működik, a csak IPv6-os úton pedig meghibásodik, a változó a hozzáférési hálózat, nem a profil. Jegyezze fel a kliensverziót és a hálózat állapotát a jegybe, mert a végső megoldás kliensfrissítés vagy más cél.

A „VPN elromlott” jelentés nem cselekvhető. A „csak IPv6-os hozzáférésen hibásodik meg” jelentés hibajelentés.

5. lépés: a hálózati utat javítsa, ne a biztonsági beállításokat

A csábító javítások mind rontanak a helyzeten. Az IPv6 kikapcsolása eltávolítja az egyetlen utat, amelyet a hálózat kínál. A kliens nyilvános feloldóra irányítása megtöri a DNS64 szintézisét, mert annak a szintézisnek a fordító mögötti feloldótól kell jönnie. A tanúsítvány-ellenőrzés kikapcsolása olyan kapcsolatot ad, amelyet nem tud azonosítani. Ezek egyike sem javítás, és közülük kettő biztonsági regresszió, amely túléli az incidenst.

A valódi lehetőségek egy olyan kliens, amely támogatja a hálózati fordítás modelljét, vagy egy elérhető IPv6-címmel rendelkező cél. Kérjen egyet ezek közül.