IPv6 përmes një serveri VPN IPv4 kërkon gjithnjë një dalje IPv6

Tuneli ngrihet, klienti merr një adresë IPv6 nga pool-i, dhe megjithatë çdo destinacion IPv6 skadon. Në tunel nuk ka asgjë të prishur: IPv6 udhëton shumë mirë brenda transportit IPv4, dhe kjo nuk ishte kurrë pjesa e vështirë. Adresa që dhatë është një premtim që serveri nuk mund ta mbajë, sepse dalja nuk ka asnjë upstream IPv6 ku ta dërgojë. Rregullimi i takon daljes, jo profilit të klientit.

Simptoma: një adresë dhe asnjë rrugë

Një kontroll nga ana e klientit tregon një adresë IPv6 me pamje globale në pajisjen e tunelit dhe një rrugë që tregon brenda saj, prandaj kjo lexohet gabimisht si defekt i klientit. Trafiku hyn në tunel, serveri e dekapsulon, dhe më pas paketa zbret në një host tabela e rrugëtimit të të cilit nuk ka asnjë rrugë të paracaktuar IPv6 drejt ndonjë vendi të vërtetë. Në varësi të stack-ut merrni papërdorshmëri të menjëhershme ose një hedhje të heshtur, dhe në të dyja rastet klienti sheh një afat kohor që duket identik me një firewall.

Lexoni tabelën e rrugëtimit të vetë serverit përpara se të prekni klientin, sepse aty banon gjysma që mungon e rrugës. Një server me një rrugë të paracaktuar IPv4 ju ka dhënë tashmë përgjigjen.

Ndiqni paketën pas dekapsulimit

Brenda tunelit paketa është IPv6 e zakonshme dhe burimi i saj është adresa e klientit. Serveri heq kapsulimin e transportit dhe më pas mban një paketë IPv6 vendase që duhet të përcillet te hop-i tjetër IPv6. Një rrugë e paracaktuar IPv4 nuk mund ta mbajë atë, dhe përkthimi i saj në IPv4 është një funksion tjetër që askush nuk e ka vënë në punë. Ky është i gjithë dështimi, dhe nuk ka asnjë lidhje me faktin nëse dëgjuesi i VPN u përgjigj apo jo përmes IPv4.

Mekanika e kapsulimit të IPv6 mbi IPv4 përshkruhet në RFC 4213, dhe detaji i rëndësishëm atje është se skajet kanë gjithnjë nevojë për lidhje IPv6 të vërtetë në anën tjetër të tunelit. Mbështjellja e një koke nuk krijon upstream.

Dy shtresa tuneli, dy kontrolle të pavarura

Verifikoni secilën shtresë veçmas, sepse një tunel i jashtëm që punon fsheh një të brendshëm të prishur. Kontrolloni rrugën e jashtme me një ping IPv4 nga klienti te serveri dhe konfirmoni portën që përdorni. Më pas kontrolloni rrugën e brendshme në server, ku ip -6 route duhet të tregojë një rrugë të paracaktuar ose një rrugë specifike të mësuar nga një upstream i vërtetë, dhe ip -6 addr duhet të tregojë një prefiks burimi që upstream-i e pranon. Çdo gjë më pak se kaq është vetëm zbukurim mbi ndërfaqen.

Një adresë unike-lokale, ose një prefiks me pamje globale drejt të cilit asgjë nuk rrugëton mbrapsht, do të shfaqet me gëzim mbi një ndërfaqe dhe nuk do të shkojë askund. Arritshmëria publike jepet nga upstream-i, jo nga forma e adresës.

E njëjta gjë vlen edhe te klienti: ip -6 route get 2001:4860:4860::8888 duhet të emërtojë pajisjen e tunelit, dhe nëse emërton atë fizike, klienti nuk po e përdor fare VPN-në për IPv6.

Prefiks burimi, madhësia dhe ICMPv6

Pyetni upstream-in se cilët prefikse burimi do të pranojë për përcjellje, dhe përdorni një prej tyre për pool-in e klientëve. Një ofrues që ju jep një /64 për ndërfaqen e vetë serverit nuk po ju rrugëton domosdoshmërisht një /64 të dytë ose një bllok më të madh, dhe diferenca është një pasdite korrigjimi që një tiketë mbështetjeje e zgjidh me një pyetje. Pyetni me shkrim dhe mbajeni përgjigjen bashkë me konfigurimin.

Parashikoni në buxhet kapsulimin shtesë që stack-u juaj përdor në të vërtetë, dhe mbani ICMPv6 në punë, duke përfshirë Packet Too Big. Një kokë e dytë e zvogëlon ngarkesën e përdorshme, kështu që një rrugë që përgjigjet ndaj ping-eve të vogla mund të dështojë gjithsesi në një transferim skedari, dhe një firewall që hedh gjithë ICMPv6 e kthen një problem madhësie të rregullueshëm në një vrimë të zezë. Provoni një transferim të madh përpara se ta shpallni shërbimin.

Çfarë është një problem krejt tjetër

Arritja e një aplikacioni vetëm-IPv4 nga një klient vetëm-IPv6 është përkthim, jo tunelizim, dhe kërkon diçka si një vendosje e qëllimshme e NAT64. Destinacioni nuk do ta kuptojë një kokë tuneli shtesë thjesht sepse shtuat një. Shërbimet historike të tranzicionit meritojnë të njëjtin kujdes: RFC 7526 hoqi modelin e releut anycast 6to4, prandaj një udhëzues i shkruar rreth tij përshkruan diçka që nuk ka më një rele publik të mirëmbajtur.

Nëse serveri nuk ka asnjë upstream IPv6 të përdorshëm, zgjedhjet janë një upstream i mbështetur, një dalje tjetër, ose një vendim i dokumentuar që IPv6 të mbetet jashtë tunelit. E papranueshme është t'u thuash klientëve se ekziston një shërbim IPv6, ndërkohë që lidhja e tyre e zakonshme IPv6 e anashkalon VPN-në në heshtje.