Ainult IPv6-ga võrk lõhub VPN-i enne, kui tunnel algab

Sülearvuti liitub konverentsi Wi-Fi-võrku, mis jagab ainult IPv6-t, VPN-klient keerleb ja ebaõnnestub, kuigi sama profiil töötas tund varem hotellis. Mandaatides ei ole midagi muutunud. Muutus see, et klient peab nüüd jõudma IPv4-sihtkohta läbi võrgu, mis kannab ainult IPv6-t, ja iga klient ei tea, kuidas seda teha.

Käige läbi samad viis sammu, mida käivad paketid.

Samm 1: jälgige nimeotsingut

Kui profiil kasutab hostinime, on esimene küsimus see, mida resolver tagastab. dig AAAA vpn.example.com ainult IPv6-ga võrgus tagastab tõelise AAAA-kirje, DNS64-st sünteesitud kirje või üldse mitte midagi. Sünteesitud vastus kodeerib IPv4-sihtkoha tõlkeprefiksi sisse ja alles siis saab IPv6-sihtkohata klient sinna jõuda. Kõvasti kodeeritud IPv4-aadressiga profiil ei jõua kunagi nii kaugele, sest sünteesida pole ühtegi nime.

See üks erinevus seletab enamikku aruandeid „seal töötab, siin ebaõnnestub“, ja selle nägemiseks kulub üks käsk.

Samm 2: vaadake, millist perekonda klient helistas

Jälgige sokkelt, mitte edenemisriba. Klient, kes avab ainult IPv6-ga lingil IPv4-sokli IPv4-aadressi vastu, ei ole seda kuhugi saata, ja tõrge ilmneb aegumisena, mitte nimeveana. ss -tanp kliendi ühendumise ajal näitab kaugemat aadressi ja perekonda, mida ta proovis. Võrrelge seda käsuga ip -6 route, et kinnitada, et vaikimisi tee on tõeline IPv6-järgmine hüpe.

Aadressiperekond soklitabelis on fakt. Edenemisriba on kellegi teise kirjutatud kokkuvõte.

Samm 3: eraldage tõlge tunnelist

NAT64 ja DNS64 on viis, kuidas juurdepääsuvõrk jõuab IPv4-sihtkohtadeni, ja need ei tee tunnelile pärast selle püstitamist midagi. Tõlgitud tee kaudu püstitatud tunnel peab endiselt läbi rääkima oma sisemise adresseerimise, ja sisemine IPv4- või IPv6-kate on eraldi poliitikaküsimus. Kui klient ühendub ja ei jõua seejärel kuhugi, olete tõlkest möödas ja marsruutimises, mis on teine uurimine teiste tõenditega.

Tõlke tõrge näeb välja nagu ei ühendu kunagi. Sisemise katte tõrge näeb välja nagu ühendub ja ei jõua kuhugi.

Samm 4: testige sama profiili teises võrgus

Viige sama profiil, kliendi versioon ja mandaadid kahe virna võrku ning korrake. Kui see töötab seal ja ebaõnnestub ainult IPv6-ga teel, on muutuja juurdepääsuvõrk, mitte profiil. Kirjutage piletisse kliendi versioon ja võrgu seisund, sest lõplik parandus on kliendi uuendus või teine sihtkoht.

Aruanne, mis ütleb, et VPN on katki, ei ole rakendatav. Aruanne, mis ütleb, et see ebaõnnestub ainult IPv6-ga juurdepääsul, on vea-aruanne.

Samm 5: parandage teed, mitte turbeseadeid

Kõik ahvatlevad parandused teevad asja hullemaks. IPv6 väljalülitamine eemaldab ainsa tee, mida võrk pakub. Kliendi suunamine avalikule resolverile lõhub DNS64 sünteesi, sest see süntees peab tulema tõlkija taga olevalt resolverilt. Sertifikaadi kontrollimise väljalülitamine annab teile ühenduse millegagi, mida te ei suuda tuvastada. Ükski neist ei ole parandus ja kaks neist on turvaregressioonid, mis jäävad juhtumist kauemaks püsima.

Tõelised valikud on klient, mis toetab võrgu tõlke mudelit, või sihtkoht, millel on kättesaadav IPv6-aadress. Küsige üht neist.