Një rrjet vetëm me IPv6 e prish VPN-në përpara se të nisë tuneli

Laptopi lidhet me një Wi-Fi konference që shpërndan vetëm IPv6, klienti VPN rrotullohet dhe dështon, ndërsa i njëjti profil kishte punuar në një hotel një orë më parë. Asgjë nuk ka ndryshuar në kredencialet. Ajo që ka ndryshuar është se klienti tani duhet të arrijë një destinacion IPv4 përmes një rrjeti që mbart vetëm IPv6, dhe jo çdo klient e di se si ta bëjë këtë.

Kaloni të njëjtat pesë hapa që kalojnë paketat.

Hapi 1: vëzhgoni kërkimin e emrit

Nëse profili përdor një emër hosti, pyetja e parë është çfarë kthen zgjidhësi. dig AAAA vpn.example.com në rrjetin vetëm me IPv6 kthen një regjistrim AAAA të vërtetë, një të sintetizuar nga DNS64, ose asgjë fare. Një përgjigje e sintetizuar kodon destinacionin IPv4 brenda një prefiksi përkthimi, dhe vetëm atëherë një klient pa destinacion IPv6 mund ta arrijë atë. Një profil me adresë IPv4 të koduar fort nuk arrin kurrë deri këtu, sepse nuk ka asnjë emër për të sintetizuar.

Ai ndryshim i vetëm shpjegon shumicën e raporteve «punon atje, dështon këtu», dhe mjafton një komandë e vetme për ta parë.

Hapi 2: shihni cilën familje thirri klienti

Vëzhgoni soketin dhe jo shiritin e përparimit. Një klient që hap një soket IPv4 drejt një adrese IPv4 në një lidhje vetëm me IPv6 nuk ka ku ta dërgojë atë, dhe dështimi shfaqet si skadim kohe dhe jo si gabim emri. ss -tanp ndërsa klienti lidhet tregon adresën e largët dhe familjen që provoi. Krahasoni atë me ip -6 route për të konfirmuar se rruga e parazgjedhur është një hop i vërtetë IPv6.

Familja e adresave në tabelën e soketëve është fakti. Shiriti i përparimit është një përmbledhje që e ka shkruar dikush tjetër.

Hapi 3: ndani përkthimin nga tuneli

NAT64 dhe DNS64 janë mënyra se si rrjeti i aksesit arrin destinacionet IPv4, dhe nuk bëjnë asgjë për tunelin pasi ai është ngritur. Një tunel i ngritur mbi një rrugë të përkthyer vazhdon të negociojë adresimin e vet të brendshëm, dhe mbulimi i brendshëm IPv4 ose IPv6 është një çështje e veçantë politikë. Nëse klienti lidhet dhe pastaj nuk arrin asgjë, ju e keni kaluar përkthimin dhe jeni në rrugëtim, që është një hetim tjetër me prova të tjera.

Dështimi i përkthimit duket si moslidhje kurrë. Dështimi i mbulimit të brendshëm duket si lidhje pa arritur asgjë.

Hapi 4: provoni të njëjtin profil në një rrjet tjetër

Çoni të njëjtin profil, versionin e klientit dhe kredencialet në një rrjet me dy shtresa dhe përsëritni. Nëse atje punon dhe dështon në rrugën vetëm me IPv6, ndryshorja është rrjeti i aksesit dhe jo profili. Shënoni në tiketë versionin e klientit dhe gjendjen e rrjetit, sepse rregullimi përfundimtar është një përditësim klienti ose një destinacion tjetër.

Një raport që thotë se VPN-i është prishur nuk është i veprueshëm. Një raport që thotë se dështon vetëm në akses vetëm me IPv6 është raport i defektit.

Hapi 5: rregulloni rrugën, jo cilësimet e sigurisë

Të gjitha rregullimet joshëse e përkeqësojnë gjendjen. Çaktivizimi i IPv6 heq rrugën e vetme që ofron rrjeti. Drejtimi i klientit nga një zgjidhës publik prish sintezën e DNS64, sepse ajo sintezë duhet të vijë nga zgjidhësi pas përkthyesit. Çaktivizimi i verifikimit të certifikatës ju jep një lidhje me diçka që nuk mund ta identifikoni. Asnjë prej tyre nuk është rregullim, dhe dy janë regresione sigurie që do t'i mbijetojnë incidentit.

Opsionet reale janë një klient që mbështet modelin e përkthimit të rrjetit, ose një destinacion me adresë IPv6 të arritshme. Kërkoni një nga këto.