IPv6 sa pamamagitan ng OpenVPN tunnel: paglalakbay sa router ng bahay

May IPv6 address ang laptop, nakaangat ang tunnel sa IPv4, pero bumabagsak ang bawat pagsubok sa IPv6. O mas masahol: pumapasa ang pagsubok at lumabas ang trapiko sa daan ng provider nang hindi man lang pumasok sa tunnel. Pareho ang patutunguhan ng dalawang resulta: isang desisyong kulang, walang nagbigay sa router ng prefix na maaari nitong i-route patungo sa mga kliyente. Ang paglakad sa daan mula sa kliyente papunta sa labas ay makikita kung aling piraso ang kulang.

Magsimula kung saan naroon ang kliyente

Tingnan ang kliyente bago hawakan ang server. Dapat magpakita ang ip -6 addr ng tunnel address mula sa pool, at dapat magpakita ang ip -6 route ng itinulak na prefix na nakaturo sa tunnel device. Kapag may address pero walang ruta, kulang ang push o binalewala ito ng kliyente. Kapag wala ang dalawa, wala talagang inilaan ang server.

Pagkatapos tingnan kung ano ang paniwala ng kliyente sa labas ng mundo. Ang default na ruta sa tunnel ay nag-aangkin ng lahat ng trapikong IPv6, samantalang ang ruta para sa 2000::/3 ay nag-aangkin lamang ng global unicast. Pareho silang maaaring tama, at sumasagot sila sa magkaibang tanong tungkol sa pagtagas.

Ang kliyenteng walang anumang default na IPv6 ay bumabagsak sa bawat pampublikong pagsubok kahit ang tunnel mismo ay ganap na malusog. Butas iyon sa patakaran, hindi sirang tunnel.

Suriin ang pool na talagang kayang i-route ng server

Ang server ay makakapaglaan lamang mula sa prefix na talagang kontrolado nito. Kung ang provider ay nagtatalaga ng /56, maglaan ng isang /64 para sa tunnel at iwan ang natitira para sa LAN. Kung ang provider ay nagbibigay lamang ng isang /64 sa WAN at wala nang iba pang ini-route, iwan ang prefix ng LAN at bigyan ang tunnel ng natatanging lokal na saklaw, na tinatanggap na walang pandaigdigang labasan ang mga kliyente.

Magkasama ang pool at ang push. Naglalaan ang server-ipv6 2001:db8:80:10::/64 ng mga address, at sinasabi ng push "route-ipv6 2000::/3" sa mga kliyente kung ano ang ipapadala sa tunnel. Ang pagtulak ng 2000::/3 ay sumasaklaw sa global unicast at iniiwan ang mga saklaw na link-local at multicast sa labas ng tunnel.

Isulat ang piniling prefix sa talaan ng paglalagay. Ang susunod na magbabago ng paghahatid ng provider ay kailangang malaman kung aling /64 ang sinasakop na ng tunnel.

Buksan ang pagpapasa para sa ikalawang pamilya

Ang pagpapasa ng IPv4 ay hindi nangangahulugang pagpapasa ng IPv6. Itakda ang net.ipv6.conf.all.forwarding=1 at ipamana ang lahat ng pinapayagan na ng patakarang FORWARD ng IPv4. Sa router na ang FORWARD chain ay nagtatapon bilang default, ang kulang na hanay ng mga tuntunin ay mukhang patay na tunnel.

Nagtagumpay ang pakikipagkamay, nakakuha ng address ang kliyente, at walang bumabalik. Magdagdag ng mga tuntunin para sa dalawang direksyon at para sa binti ng WAN, dahil ang tunnel na umaabot sa LAN pero hindi sa internet ay bumabagsak sa ikatlong pagsubok. Pagkatapos ng nabigong pagtatangka tingnan ang mga counter ng chain, dahil ang tuntuning hindi kailanman tumugma ay ibang problema kaysa sa tumugma at nagtapon.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Isang side effect ang humuhuli sa mga sa huli ay sinisisi ang tunnel. Kapag binuksan ang pagpapasa, nilalaktawan ng kernel ang pag-configure ng address sa pamamagitan ng Router Advertisement maliban kung sabihin, at ang default na rutang natutunan sa ganoong paraan ay nawawala kasama nito. Maaaring i-pin ang isang tahasang default na ruta sa WAN interface, o sadyang itakda ang accept_ra sa 2 doon. Pagkatapos ng alinmang pagbabago, tiyakin na mayroon pa ring magagamit na daan ng IPv6 palabas ang router bago subukan muli ang mga kliyente.

Sagutin ang pagtuklas ng kapitbahay kapag hindi nag-route ang upstream

Minsan ay itinuturing ng kagamitan sa upstream ang itinalagang /64 na bahagi ng sarili nitong link at tumatangging i-route ang anumang sub-prefix patungo sa kahon ng VPN. Kapag nangyari iyon, may dapat sumagot sa mga kahilingan ng kapitbahay para sa bawat address ng kliyente nang isa-isa.

Inilalantad ng OpenVPN ang itinalagang address sa isang client-connect hook, kaya masusundan ng mga entry ang tunay na pool sa halip na listahang pinapanatili sa kamay. Nagdaragdag ang hook ng ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, at tinatanggal ito ng katugmang client-disconnect hook. Kung walang pagtanggal, napaglumaan ang proxy table at ang susunod na kliyente ay maaaring magmana ng entry para sa address na hindi niya natanggap. Tiyakin ang kalagayan gamit ang ip -6 neigh show proxy.

Ituring ang proxy na pansamantalang solusyon. Ang static na ruta para sa /64 ng tunnel na nakaturo sa router ay tumatagal sa pagpapalit ng kliyente at hindi nangangailangan ng anumang privileged na shell hook.

Sundan ang daan palabas, hop bawat hakbang

Subukan palabas sa tatlong hakbang: una ang tunnel address ng router, pagkatapos ay isang host sa LAN, at ikatlo ang pampublikong patutunguhan sa pamamagitan ng traceroute6. Ang pool ay pinatutunayan ng una, ang pagpapasa at firewall ng LAN ng pangalawa, at ang daan pabalik sa upstream ng pangatlo. Ang bawat kabiguan ay nagpapaliit ng paghahanap sa isang aparato sa halip na buksan muli ang buong disenyo.

Bantayan ang MTU ng tunnel, dahil ang mga router na IPv6 sa daan ay hindi mag-fragment para sa iyo. Ang sobrang laking MTU ay lumilitaw bilang error na packet-too-big at natigil na TLS sa halip na malinis na kabiguan. Itakda ito nang tahasan at subukan gamit ang kargang malapit sa limitasyon.