Tik IPv6 turintis tinklas sugadina VPN dar neprasidėjus tuneliui

Nešiojamasis kompiuteris prisijungia prie konferencijos Wi-Fi, kuris dalija tik IPv6, VPN klientas sukasi ir nepavyksta, nors ta pati profilis prieš valandą veikė viešbutyje. Kredencialuose nieko nepasikeitė. Pasikeitė tai, kad klientas dabar turi pasiekti IPv4 paskirties tašką per tinklą, kuris neša tik IPv6, ir ne kiekvienas klientas žino, kaip tai padaryti.

Pereikite tuos pačius penkis žingsnius, kuriuos pereina paketai.

1 žingsnis: stebėkite vardo paiešką

Jei profilis naudoja hosto vardą, pirmas klausimas yra, ką grąžina resolveris. dig AAAA vpn.example.com tik IPv6 tinkle grąžina tikrą AAAA įrašą, DNS64 sintetintą įrašą arba nieko. Sintetintas atsakymas užkoduoja IPv4 paskirties tašką vertimo prefikse, ir tik tada klientas be IPv6 paskirties taško gali jį pasiekti. Profilis su kietai įrašytu IPv4 adresu niekada nepasiekia šio etapo, nes nėra vardo, kurį būtų galima sintetinti.

Šis vienintelis skirtumas paaiškina daugumą „ten veikia, čia nepavyksta“ ataskaitų, ir jam pamatyti užtenka vienos komandos.

2 žingsnis: pažiūrėkite, kurią šeimą klientas iškvietė

Stebėkite lizdą, o ne progreso juostą. Klientas, atidarantis IPv4 lizdą į IPv4 adresą tik IPv6 jungtyje, neturi kur jo siųsti, o gedimas pasireiškia kaip laiko limitas, o ne kaip vardo klaida. ss -tanp klientui jungiantis rodo nuotolinį adresą ir šeimą, kurią jis bandė. Palyginkite tai su ip -6 route, kad patvirtintumėte, jog numatytasis maršrutas yra tikras IPv6 kitas šuolis.

Adresų šeima lizdų lentelėje yra faktas. Progreso juosta yra kito žmogaus parašyta santrauka.

3 žingsnis: atskirkite vertimą nuo tunelio

NAT64 ir DNS64 yra būdas, kuriuo prieigos tinklas pasiekia IPv4 paskirties taškus, ir jie nieko nedaro tuneliui, kai šis jau pakeltas. Per verstą kelią sukurtas tunelis vis tiek derasi dėl savo vidinio adresavimo, o vidinė IPv4 ar IPv6 aprėptis yra atskiras politikos klausimas. Jei klientas prisijungia ir tada nieko nepasiekia, jūs jau praėjote vertimą ir esate maršrutizavime, o tai yra kitas tyrimas su kitais įrodymais.

Vertimo gedimas atrodo kaip niekada neprisijungimas. Vidinės aprėpties gedimas atrodo kaip prisijungimas ir nieko nepasiekimas.

4 žingsnis: išbandykite tą pačią profilį kitame tinkle

Nuneškite tą pačią profilį, kliento versiją ir kredencialus į dvigubo kamino tinklą ir pakartokite. Jei ten veikia, o tik IPv6 kelyje nepavyksta, kintamasis yra prieigos tinklas, o ne profilis. Užrašykite biliete kliento versiją ir tinklo būseną, nes galutinis sprendimas yra kliento atnaujinimas arba kitas paskirties taškas.

Ataskaita, sakanti, kad VPN sulaužyta, yra netinkama veikti. Ataskaita, sakanti, kad nepavyksta tik IPv6 prieigoje, yra klaidos ataskaita.

5 žingsnis: taisykite kelią, o ne saugumo nustatymus

Visi viliojantys taisymai viską daro blogiau. Išjungus IPv6 pašalinamas vienintelis tinklo siūlomas kelias. Nukreipus klientą į viešą resolverį sugadinama DNS64 sintezė, nes ta sintezė turi ateiti iš resolverio už vertėjo. Išjungus sertifikato tikrinimą gaunate ryšį su kažkuo, ko negalite atpažinti. Nė vienas iš jų nėra taisymas, o du iš jų yra saugumo regresijos, kurios pergyvens incidentą.

Tikros galimybės yra klientas, palaikantis tinklo vertimo modelį, arba paskirties taškas su pasiekiamu IPv6 adresu. Paprašykite vieno iš jų.