Binabasag ng network na IPv6 lang ang VPN bago pa magsimula ang tunnel

Kumokonekta ang laptop sa Wi-Fi ng kumperensya na IPv6 lang ang ibinibigay, umiikot at nabigo ang kliyente ng VPN, at gumana ang parehong profile sa isang hotel isang oras kanina. Walang nagbago sa mga kredensyal. Ang nagbago ay kailangan na ngayong maabot ng kliyente ang destinasyong IPv4 sa pamamagitan ng network na IPv6 lang ang dala, at hindi alam ng bawat kliyente kung paano ito gawin.

Daanan ang parehong limang hakbang na dinaraanan ng mga packet.

Hakbang 1: panoorin ang paghahanap ng pangalan

Kung gumagamit ang profile ng hostname, ang unang tanong ay kung ano ang ibinabalik ng resolver. Ang dig AAAA vpn.example.com sa network na IPv6 lang ay nagbabalik ng tunay na AAAA record, isang sintetiko mula sa DNS64, o wala talaga. Ang sintetikong sagot ay naka-encode ang destinasyong IPv4 sa loob ng prefix ng pagsasalin, at doon pa lang maaabot ito ng kliyenteng walang destinasyong IPv6. Ang profile na may hard-coded na address na IPv4 ay hindi kailanman nakakaabot dito, dahil walang pangalan na isi-synthesize.

Ang nag-iisang pagkakaibang iyon ang nagpapaliwanag sa karamihan ng ulat na «gumagana doon, nabigo dito», at isang utos lang ang kailangan para makita ito.

Hakbang 2: tingnan kung aling pamilya ang tinawag ng kliyente

Tingnan ang socket sa halip na ang progress bar. Ang kliyenteng nagbubukas ng socket na IPv4 patungo sa address na IPv4 sa link na IPv6 lang ay walang mapagpadalhan nito, at lumalabas ang pagkabigo bilang timeout sa halip na error sa pangalan. Ang ss -tanp habang kumokonekta ang kliyente ay nagpapakita ng malayong address at ng pamilyang sinubukan nito. Ihambing iyon sa ip -6 route upang kumpirmahin na ang default ay tunay na susunod na hop na IPv6.

Ang pamilya ng address sa talahanayan ng socket ang katotohanan. Ang progress bar ay buod na isinulat ng ibang tao.

Hakbang 3: ihiwalay ang pagsasalin sa tunnel

Ang NAT64 at DNS64 ang paraan ng pag-abot ng access network sa mga destinasyong IPv4, at wala silang ginagawa para sa tunnel kapag nakatayo na ito. Ang tunnel na itinayo sa isang naisaling landas ay nakikipagnegosyo pa rin sa sarili nitong panloob na addressing, at ang panloob na saklaw na IPv4 o IPv6 ay hiwalay na usapin ng patakaran. Kung kumonekta ang kliyente at pagkatapos ay walang naabot, lampas ka na sa pagsasalin at nasa routing ka na, na isa pang imbestigasyon na may ibang ebidensya.

Ang pagkabigo ng pagsasalin ay mukhang hindi kailanman kumonekta. Ang pagkabigo ng panloob na saklaw ay mukhang kumonekta na walang naabot.

Hakbang 4: subukan ang parehong profile sa ibang network

Dalhin ang parehong profile, bersyon ng kliyente at mga kredensyal sa network na dual-stack at ulitin. Kung gumagana doon at nabigo sa landas na IPv6 lang, ang variable ay ang access network at hindi ang profile. Itala sa ticket ang bersyon ng kliyente at ang kalagayan ng network, dahil ang panghuling pagtatama ay update ng kliyente o ibang destinasyon.

Ang ulat na nagsasabing sira ang VPN ay hindi maaaksyunan. Ang ulat na nagsasabing nabigo lamang sa access na IPv6 lang ay ulat ng bug.

Hakbang 5: ayusin ang landas, hindi ang mga setting ng seguridad

Ang lahat ng nakakaakit na pagtatama ay nagpapalala ng lahat. Ang pagpapatay ng IPv6 ay nag-aalis ng nag-iisang landas na iniaalok ng network. Ang pagturo sa kliyente sa publikong resolver ay sumisira sa synthesis ng DNS64, dahil ang synthesis na iyon ay dapat magmula sa resolver sa likod ng tagasalin. Ang pagpapatay ng beripikasyon ng sertipiko ay nagbibigay sa iyo ng koneksyon sa isang bagay na hindi mo matukoy. Wala sa mga iyon ang pagtatama, at dalawa sa kanila ay pagregress ng seguridad na mas matatagal pa sa insidente.

Ang tunay na mga opsyon ay isang kliyenteng sumusuporta sa modelo ng pagsasalin ng network, o isang destinasyong may naaabot na address na IPv6. Hilingin ang isa sa mga iyon.