Reto nur kun IPv6 rompas la VPN antaŭ ol la tunelo startas

La tekkomputilo aliĝas al konferenca Wi-Fi, kiu disdonas nur IPv6, la VPN-kliento turniĝas kaj malsukcesas, kaj la sama profilo funkciis en hotelo unu horon pli frue. Nenio en la akreditaĵoj ŝanĝiĝis. Kio ŝanĝiĝis estas, ke la kliento nun devas atingi IPv4-celon tra reto, kiu portas nur IPv6, kaj ne ĉiu kliento scias, kiel fari tion.

Iru la samajn kvin paŝojn, kiujn iras la pakaĵoj.

Paŝo 1: observu la nomserĉon

Se la profilo uzas gastigantnomon, la unua demando estas, kion redonas la solvilo. dig AAAA vpn.example.com en la reto nur kun IPv6 redonas veran AAAA-rikordon, unu sintezitan el DNS64, aŭ tute nenion. Sintezita respondo kodas la IPv4-celon ene de traduka antaŭfikso, kaj nur tiam kliento sen IPv6-celo povas atingi ĝin. Profilo kun malmola IPv4-adreso neniam venas ĝis ĉi tie, ĉar mankas nomo por sintezi.

Tiu sola diferenco klarigas la plej multajn raportojn «funkcias tie, malsukcesas ĉi tie», kaj unu komando sufiĉas por vidi ĝin.

Paŝo 2: vidu, al kiu familio la kliento telefonis

Observu la soketon anstataŭ la progresbreton. Kliento, kiu malfermas IPv4-soketon al IPv4-adreso sur ligilo nur kun IPv6, havas nenie por sendi ĝin, kaj la fiasko aperas kiel tempolimo anstataŭ nomeraro. ss -tanp dum la kliento konektiĝas montras la malproksiman adreson kaj la familion, kiun ĝi provis. Komparu tion kun ip -6 route por konfirmi, ke la implicita vojo estas vera IPv6-sekva salto.

La adresfamilio en la soketa tabelo estas la fakto. La progresbreto estas resumo, kiun iu alia skribis.

Paŝo 3: apartigu la tradukon de la tunelo

NAT64 kaj DNS64 estas kiel la alira reto atingas IPv4-celojn, kaj ili faras nenion por la tunelo post kiam ĝi staras. Tunelo starigita super tradukita vojo ankoraŭ interkonsentas sian propran internan adresadon, kaj la interna IPv4 aŭ IPv6-kovrado estas aparta politika demando. Se la kliento konektiĝas kaj poste atingas nenion, vi jam pasis la tradukon kaj eniris la enkursigadon, kio estas alia esploro kun aliaj pruvoj.

Fiaskanta traduko aspektas kiel neniam konektiĝi. Fiaskanta interna kovrado aspektas kiel konektiĝi kaj atingi nenion.

Paŝo 4: testu la saman profilon en alia reto

Prenu la saman profilon, klientversion kaj akreditaĵojn al duobla-staka reto kaj ripetu. Se ĝi funkcias tie kaj malsukcesas sur la vojo nur kun IPv6, la variablo estas la alira reto, ne la profilo. Notu la klientversion kaj la retan kondiĉon en la bileto, ĉar la fina solvo estas klienta ĝisdatigo aŭ alia celo.

Raporto diranta, ke la VPN estas rompita, ne estas plenumebla. Raporto diranta, ke ĝi malsukcesas nur ĉe aliro nur kun IPv6, estas cimraporto.

Paŝo 5: ripari la vojon, ne la sekurecajn agordojn

La tentaj riparoj ĉiuj plimalbonigas la aferojn. Malŝalti IPv6 forigas la solan vojon, kiun la reto proponas. Direkti la klienton al publika solvilo rompas la DNS64-sintezon, ĉar tiu sintezo devas veni de la solvilo malantaŭ la tradukilo. Malŝalti la atestilan kontroladon donas al vi konekton al io, kion vi ne povas identigi. Neniu el tiuj estas riparo, kaj du el ili estas sekurecaj regresoj, kiuj postvivos la incidenton.

La veraj ebloj estas kliento, kiu subtenas la rettradukan modelon, aŭ celo kun atingebla IPv6-adreso. Petu unu el tiuj.