Ang paghahati ng iyong /64 ay hindi nagruruta ng IPv6 sa mga kliyente ng VPN

Ipinapakita ng kliyente ang isang global na IPv6 address, natapos ang handshake, at walang bumabalik mula sa internet. Mukhang tama ang setting ng pool dahil tama ito; wasto ang address at dinadala ito ng tunnel. Ang nabigo ay ang paghahatid, at ang paghahatid ay nakasalalay sa isang desisyong ginawa sa itaas ng server ng VPN na walang anumang configuration sa panig ng kliyente ang makakaimpluwensya.

Ang mito: ang isang bahagi ng iyong /64 ay naaabot na

Kaakit-akit ang kuwento: may pampublikong /64 ang server, hatiin ito sa dalawa, ibigay ang kabilang kalahati sa pool ng VPN, at ang mga kliyenteng iyon ay nasa internet na. Ang paghahati ng prefix ay talagang naglalaan ng mga address nang walang banggaan. Ngunit hindi nito binabago kung paano nagpapasya ang network ng upstream kung saan dapat pumunta ang packet para sa isa sa mga address na iyon.

Walang default na layer ng pagsasalin ang IPv6 na maaaring sandalan, kaya ang daan pabalik ay dapat umiral bilang routing o bilang paghahatid sa antas ng link. Ang packet na naka-address sa tunnel address ng kliyente ay dumarating sa router ng upstream, at ang router na iyon ay gumagawa ng desisyon sa pagpapasa mula sa sarili nitong talahanayan. Kung ang talahanayan ay tumuturo sa pisikal na link, pumupunta doon ang packet, anuman ang paniwalaan ng iyong server ng VPN.

Iyon ang buong kabiguan: gumagana ang direksyon pasulong dahil ipinapadala ito ng iyong server, at namamatay ang direksyon pabalik isang hop ang layo dahil hindi kailanman nalaman ng upstream na may kliyente.

Ano ang tunay na kailangan ng paghahatid sa link

Kapag itinuturing ng upstream na ang buong /64 ay nasa pisikal na link, nilulutas nito ang bawat destinasyong address sa pamamagitan ng pagtuklas ng kapitbahay. Nagpapadala ito ng kahilingan sa link na iyon at inaasahang sasagot ang may-ari ng address. Ang kliyente ng VPN na nasa likod ng tunnel ay wala sa link na iyon at hindi makakasagot, kaya nananatiling walang sagot ang kahilingan at itinatapon ang packet.

Ang paghiwa ng /65 ay hindi nagbabago sa inaasahang iyon. Itinuturing pa rin ng upstream ang saklaw na nasa link, dahil ang tanging bagay na magbabago ng isip nito ay isang ruta o proxy na sumasagot sa ngalan ng kliyente. Wala sa dalawa ang lumilitaw dahil binago mo ang isang configuration ng VPN. Ang puwang na iyon ang dahilan kung bakit ang isang pool ay maaaring gumana nang perpekto sa pagitan ng sarili nitong mga kliyente at gayunpaman ay hindi maabot mula saanman.

Ang pagtuklas ng kapitbahay sa pamamagitan ng proxy ang mekanismong makakapag-ugnay sa dalawang mundo. Sinasagot ng gateway ang mga kahilingan para sa mga partikular na address ng kliyente na pag-aari nito at ipinapasa ang trapiko sa tunnel. Gumagana ito, at dapat itong limitahan nang eksakto sa mga address na iyon na may lifecycle na sumusunod sa pool, dahil ang pagsagot para sa address na hindi mo na pinaglilingkuran ay ginagawang itim na butas ang trapiko ng iba. Hindi tatanggapin ng ilang upstream ang mga sagot ng proxy na hindi nila inaasahan, kaya kailangan din ng pahintulot ng provider ang disenyong ito.

Ano ang kailangan ng nirurutang paghahatid

Ang mas malinis na disenyo ay isang allocation na talagang niruruta ng upstream sa iyong gateway. Maaaring ito ay isang delegated prefix o isang static na ruta para sa mas maliit na bloke, at pareho ang pangangailangan sa dalawang kaso: dapat ituro ng talahanayan ng upstream ang iyong server para sa saklaw ng kliyente. Pagkatapos ay dumarating ang trapikong pabalik sa gateway at ipinapasa ito ng gateway sa tunnel.

Inaalis ng nirurutang paghahatid ang tanong ng pagtuklas ng kapitbahay nang buo, kaya sulit itong hilingin sa provider bago magtayo ng anumang matalino. Hilingin ang ruta nang nakasulat, at tiyakin na ang susunod na hop ay ang address na talagang maaabot ng upstream.

Ang parehong disenyo ay nangangailangan pa rin ng forwarding ng IPv6 na naka-enable sa gateway at mga panuntunan ng firewall na nagpapahintulot sa ipinasang daloy sa parehong direksyon. Ang paghahatid ay isang paunang kondisyon, hindi isang kapalit, para sa natitirang bahagi ng landas. Ang gumaganang ruta na naka-off ang forwarding ay gumagawa ng eksaktong parehong katahimikan tulad ng nawawalang ruta, kaya suriin ang pareho bago magdisenyo muli ng anuman.

Dalawang independiyenteng ruta na dapat gawing tama

Ang prefix ng pool at ang sariling default na ruta ng kliyente ay magkahiwalay na setting, at ang paghahalo sa mga ito ay gumagawa ng bahagyang pagkakakonekta na mukhang sirang tunnel. Sinasabi ng pool sa server kung aling mga address ang ibibigay. Ang mga ruta ng kliyente ang nagpapasya kung saang mga destinasyon ipinapadala ng kliyente ang trapiko sa tunnel.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Ang prefix sa itaas ay espasyo ng dokumentasyon, at ang redirect ay nalalapat lamang sa IPv6, na siyang eksaktong kailangan ng dual-stack deployment habang inaayos pa ang paghahatid ng IPv6. Ang redirect ng IPv4 ay hindi nagtatatag ng saklaw ng IPv6, at wala sa dalawang setting ang nagpapahiwatig ng isa.

Panatilihing gumagana ang trapikong kontrol na pinagkakatiwalaan ng IPv6 sa ilalim ng anumang patakarang inilalapat mo. Ang mga mensaheng Packet Too Big ang klasikong biktima ng firewall na pinapayagan lamang ang TCP at UDP, at ang pagtatapon sa mga ito ay gumagawa ng mga koneksyon na naitatatag at pagkatapos ay natigil sa mas malalaking paglilipat.

Ang mga anunsyo ng router ang ikatlong gumagalaw na bahagi. Kung magsimulang mag-anunsyo ang gateway sa uplink, maaaring mabago nito ang pinaniniwalaan ng mga kliyente at kapitbahay tungkol sa mga prefix sa link, na maaaring tahimik na magpawalang-bisa sa disenyong kabisado mo lang idokumento.

Itala ang disenyo upang maulit ito ng muling pagtatayo

Isulat nang hiwalay ang tatlong bagay: ang allocation ng kliyente, ang destinasyong ruta ng kliyente, at ang paraan ng paghahatid ng upstream para sa allocation. Ang mambabasang may tatlong ito ay makakagawa muli ng deployment; ang mambabasang may setting ng pool lamang ay uulitin ang orihinal na bug.

Pagkatapos ay tahasang subukan ang direksyon pabalik, gamit ang packet na kailangang bumalik mula sa labas. Sinasaklaw ng manual ng openvpn(8) ang mga opsyon ng server-ipv6 at redirect, at sinasaklaw ng kumpirmasyon ng routing mula sa iyong provider ang kalahating hindi kayang saklawin ng manual.