Klēpjdators pievienojas konferences Wi-Fi, kas izdala tikai IPv6, VPN klients griežas un cieš neveiksmi, lai gan tā pati profils stundu iepriekš darbojās viesnīcā. Akreditācijas datos nekas nav mainījies. Mainījies ir tas, ka klientam tagad jāsasniedz IPv4 galamērķis caur tīklu, kas pārvadā tikai IPv6, un ne katrs klients zina, kā to izdarīt.

Izejiet tos pašus piecus soļus, ko iziet paketes.

1. solis: vērojiet nosaukuma meklēšanu

Ja profils izmanto resursdatora nosaukumu, pirmais jautājums ir, ko atgriež atrisinātājs. dig AAAA vpn.example.com tīklā tikai ar IPv6 atgriež īstu AAAA ierakstu, DNS64 sintezētu ierakstu vai neko. Sintezētā atbilde iekodē IPv4 galamērķi tulkošanas prefiksā, un tikai tad klients bez IPv6 galamērķa var to sasniegt. Profils ar cieti iekodētu IPv4 adresi nekad netiek tik tālu, jo nav nosaukuma, ko sintezēt.

Šī vienīgā atšķirība izskaidro lielāko daļu „tur strādā, šeit neizdodas“ ziņojumu, un tās redzēšanai pietiek ar vienu komandu.

2. solis: skatiet, kuru saimi klients izsauca

Vērojiet ligzdu, nevis progresa joslu. Klientam, kas atver IPv4 ligzdu uz IPv4 adresi saitē tikai ar IPv6, nav kur to nosūtīt, un kļūme izpaužas kā taimauts, nevis kā nosaukuma kļūda. ss -tanp klientam savienojoties parāda attālo adresi un saimi, kuru tas mēģināja. Salīdziniet to ar ip -6 route, lai apstiprinātu, ka noklusējums ir īsts IPv6 nākamais lēciens.

Adrešu saime ligzdu tabulā ir fakts. Progresa josla ir kāda cita rakstīts kopsavilkums.

3. solis: atdaliet tulkošanu no tuneļa

NAT64 un DNS64 ir veids, kā piekļuves tīkls sasniedz IPv4 galamērķus, un tie neko nedara tunelim pēc tā pacelšanas. Tunelis, kas izveidots pāri tulkotam ceļam, joprojām pārrunā savu iekšējo adresāciju, un iekšējais IPv4 vai IPv6 pārklājums ir atsevišķs politikas jautājums. Ja klients savienojas un pēc tam neko nesasniedz, jūs jau esat pāri tulkošanai un esat maršrutēšanā, kas ir cita izmeklēšana ar citiem pierādījumiem.

Tulkošanas kļūme izskatās kā nekad nesavienojas. Iekšējā pārklājuma kļūme izskatās kā savienojas un neko nesasniedz.

4. solis: pārbaudiet to pašu profilu citā tīklā

Aiznesiet to pašu profilu, klienta versiju un akreditācijas datus uz divkāršas kaudzes tīklu un atkārtojiet. Ja tur strādā un tikai IPv6 ceļā neizdodas, mainīgais ir piekļuves tīkls, nevis profils. Pierakstiet biļetē klienta versiju un tīkla stāvokli, jo galīgais risinājums ir klienta atjauninājums vai cits galamērķis.

Ziņojums, ka VPN ir salauzts, nav izpildāms. Ziņojums, ka tas neizdodas tikai piekļuvē tikai ar IPv6, ir kļūdas ziņojums.

5. solis: labojiet ceļu, nevis drošības iestatījumus

Visi vilinošie labojumi visu padara sliktāku. IPv6 izslēgšana noņem vienīgo ceļu, ko tīkls piedāvā. Klienta novirzīšana uz publisku atrisinātāju salauž DNS64 sintēzi, jo šai sintēzei jānāk no atrisinātāja aiz tulkotāja. Sertifikāta pārbaudes izslēgšana dod jums savienojumu ar kaut ko, ko nevarat identificēt. Neviens no tiem nav labojums, un divi no tiem ir drošības regresijas, kas pārdzīvos incidentu.

Īstās iespējas ir klients, kas atbalsta tīkla tulkošanas modeli, vai galamērķis ar sasniedzamu IPv6 adresi. Palūdziet vienu no tiem.

Saistītie raksti