Ang IPv6 sa pamamagitan ng IPv4 VPN server ay nangangailangan pa rin ng IPv6 exit

Bumangon ang tunnel, tumatanggap ang kliyente ng IPv6 address mula sa pool, at nag-e-expire pa rin ang bawat IPv6 destinasyon. Walang sira sa loob ng tunnel: maayos na tumatakbo ang IPv6 sa loob ng IPv4 transport, at hindi kailanman iyon ang mahirap na bahagi. Ang address na ibinigay mo ay isang pangakong hindi matutupad ng server, dahil walang IPv6 upstream ang exit na pagpapadalhan nito. Ang pag-aayos ay nasa exit, hindi sa profile ng kliyente.

Ang sintomas: may address, walang ruta

Ang pagsusuri sa panig ng kliyente ay nagpapakita ng IPv6 address na mukhang global sa tunnel device at ruta na tumuturo rito, kaya mali itong binabasa bilang bug ng kliyente. Pumapasok ang trapiko sa tunnel, dine-decapsulate ito ng server, at pagkatapos ay lumalapag ang packet sa host na ang routing table ay walang default na ruta ng IPv6 papunta sa totoong lugar. Depende sa stack, nakakakuha ka ng agad na hindi maabot o tahimik na pagtatapon, at sa dalawang kaso ay nakikita ng kliyente ang timeout na mukhang kapareho ng firewall.

Basahin ang sariling routing table ng server bago hawakan ang kliyente, dahil doon nakatira ang nawawalang kalahati ng ruta. Ang server na may isang default na ruta ng IPv4 ay naibigay na sa iyo ang sagot.

Sundan ang packet pagkatapos ng decapsulation

Sa loob ng tunnel ang packet ay ordinaryong IPv6 at ang pinagmulan nito ay ang address ng kliyente. Tinatanggal ng server ang transport encapsulation at pagkatapos ay may hawak na native IPv6 packet na dapat ipasa sa susunod na IPv6 hop. Hindi ito madadala ng default na ruta ng IPv4, at ang pagsasalin nito sa IPv4 ay ibang function na walang nag-deploy. Iyon ang buong pagkabigo, at wala itong kinalaman sa kung sumagot ang VPN listener sa IPv4.

Ang mekaniks ng IPv6-over-IPv4 encapsulation ay inilarawan sa RFC 4213, at ang mahalagang detalye doon ay kailangan pa rin ng mga endpoint ng tunay na IPv6 connectivity sa kabilang panig ng tunnel. Ang pagbabalot ng header ay hindi gumagawa ng upstream.

Dalawang layer ng tunnel, dalawang independiyenteng pagsusuri

I-verify ang bawat layer nang hiwalay, dahil ang gumaganang panlabas na tunnel ay nagtatago ng sirang panloob. Suriin ang panlabas na ruta gamit ang IPv4 ping mula sa kliyente patungo sa server at kumpirmahin ang port na ginagamit mo. Pagkatapos ay suriin ang panloob na ruta sa server, kung saan ip -6 route dapat magpakita ng default o partikular na rutang natutunan mula sa tunay na upstream, at ip -6 addr dapat magpakita ng source prefix na tinatanggap ng upstream. Anumang mas mababa pa riyan ay dekorasyon lamang sa interface.

Ang unique-local na address, o prefix na mukhang global na walang nagruruta pabalik dito, ay masayang lalabas sa interface at hindi pupunta kahit saan. Ang pampublikong maabot ay ibinibigay ng upstream, hindi ng hugis ng address.

Ganoon din sa kliyente: ip -6 route get 2001:4860:4860::8888 dapat nitong pangalanan ang tunnel device, at kung ang pisikal ang pinapangalanan nito, hindi talaga ginagamit ng kliyente ang VPN para sa IPv6.

Source prefix, laki at ICMPv6

Tanungin ang upstream kung aling mga source prefix ang tatanggapin nito para sa forwarding, at gamitin ang isa sa mga ito para sa client pool. Ang provider na nagbibigay sa iyo ng /64 para sa sariling interface ng server ay hindi laging nagruruta ng pangalawang /64 o mas malaking block sa iyo, at ang pagkakaiba ay isang hapon ng debugging na sinasagot ng support ticket sa isang tanong. Itanong ito sa sulat at itago ang sagot kasama ng configuration.

Maglaan ng badyet para sa dagdag na encapsulation na talagang ginagamit ng iyong stack, at panatilihing gumagana ang ICMPv6, kasama ang Packet Too Big. Ang pangalawang header ay nagpapaliit sa magagamit na payload, kaya ang rutang sumasagot sa maliliit na ping ay maaari pa ring mabigo sa paglilipat ng file, at ang firewall na nagtatapon ng lahat ng ICMPv6 ay ginagawang black hole ang isang naaayos na problema sa laki. Subukan ang isang malaking paglilipat bago ipahayag ang serbisyo.

Ano ang ganap na ibang problema

Ang pag-abot sa aplikasyong IPv4 lamang mula sa kliyenteng IPv6 lamang ay pagsasalin, hindi tunneling, at nangangailangan ng isang bagay na tulad ng sadyang naka-deploy na NAT64. Hindi maiintindihan ng destinasyon ang dagdag na tunnel header dahil lang nagdagdag ka ng isa. Ang mga makasaysayang transition service ay karapat-dapat sa parehong pag-iingat: inalis ng RFC 7526 ang anycast relay model ng 6to4, kaya ang gabay na nakasulat sa paligid nito ay naglalarawan ng bagay na wala nang pinapanatili pang pampublikong relay.

Kung ang server ay walang magagamit na IPv6 upstream, ang mga pagpipilian ay isang sinusuportahang upstream, ibang exit, o isang dokumentadong desisyon na mananatili ang IPv6 sa labas ng tunnel. Ang hindi katanggap-tanggap ay sabihin sa mga kliyente na may serbisyong IPv6 habang ang kanilang ordinaryong koneksyon sa IPv6 ay tahimik na lumalampas sa VPN.