Dapat Bang Dumaan sa VPN o Direkta ang Trapikong IPv6?
Magpasya kung kabilang ang ::/0 sa loob ng tunel, gamit ang tatlong kondisyon: suporta ng labasan, abot ng dulong dulo at mga lokal na network lamang.
Noong nakaraang buwan, dalawang tao ang humingi sa akin ng magkasalungat na resulta: gusto ng isa na sakop ng VPN ang IPv6, gusto ng iba na patuloy na gumana ang printer sa opisina. Hindi kayang ibigay ng isang ruta ::/0 ang dalawa nang mag-isa. Kung kabilang ang rutang iyon sa loob ng tunel ay depende sa tatlong kondisyon, at ang una ay nag-aalis nito para sa karamihan ng komersyal na labasan. Kung hindi nagdadala ng IPv6 ang labasan, itinatago ng paghahatid ng default na ruta doon ang iyong trapiko sa isang tunel na walang mapagpadalhan.
Tatlong kondisyon ang nagtatakda ng sagot
Ang default na ruta ay isang linya, ::/0, at tumutugma ito sa anumang destinasyong IPv6 na walang mas tiyak na ruta (RFC 4291). Madaling i-install ito. Ang pagpapasya kung dapat mong gawin ay bumabalik sa tatlong kondisyon.
Unang kondisyon: ang labasan na kinokonektahan mo ay may gumaganang IPv6 at handa itong ipasa. Ikalawang kondisyon: kayang panatilihin ng iyong kliyente ang landas patungo sa dulong dulo ng tunel, na karaniwang nasa loob ng saklaw na iruruta mo. Ikatlong kondisyon: mababanggit mo ang mga lokal na destinasyong IPv6 na dapat manatili sa labas ng tunel.
Bawat kondisyon ay nabibigo sa sarili nitong paraan, kaya ang paghula ay nagkakahalaga ng isang buong gabi. Ang nabigong unang kondisyon ay nagbibigay sa iyo ng katahimikan at isang talahanayan ng ruta na mukhang tama. Ang nabigong ikalawang kondisyon ay pumapatay sa handshake ilang segundo pagkatapos nitong magsimula. Ang nabigong ikatlong kondisyon ay nag-iiwan ng gumaganang tunel at isang hindi nasisiyahang katrabaho sa printer.
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
Talaga bang nagdadala ng IPv6 ang labasan?
Ang interface ng tunel na may address na IPv6 ay walang pinapatunayan tungkol sa kabilang panig. Maraming komersyal na profile ay IPv4 lamang sa loob: binibigyan ka ng server ng address na v4 at itinatapon ang lahat ng iba. Maglagay ng default na ruta mula sa AllowedIPs sa ibabaw nito at masayang magpapadala ang kernel ng IPv6 sa isang interface na hindi kailanman nakikita ng katapat nito.
Subukan mula sa kliyente habang nakaangat ang tunel. ping -6 -c 3 2001:4860:4860::8888 at ip -6 route get 2001:4860:4860::8888 ay sumasagot sa magkaibang tanong: kung may bumabalik na sagot, at kung aling device ang pinili ng kernel. Kapag binanggit ng pangalawa ang iyong tunel at walang ibinalik ang una, ang problema ay sa labasan, hindi sa ruta.
Kung ikaw mismo ang nagpapatakbo ng labasan, maaaring pumasa ang pagsubok ng kliyente at mauwi pa rin sa dead end ang landas. Kumpirmahin na net.ipv6.conf.all.forwarding=1 ay aktibo sa gateway at tinatanggap ng firewall nito ang mga packet na ipinapasa palabas ng tunel. Ang packet na tamang na-ruta patungo sa labasang tumatangging magpasa ay mukhang eksaktong bug sa pagruruta mula sa panig ng kliyente.
Kaya bang panatilihin ng kliyente ang landas nito patungo sa dulong dulo?
Ito ang kaso na humuli sa akin sa isang laptop na may dulong dulo ng WireGuard na IPv6 lamang. Ang address ng dulong dulo ay ordinaryong pandaigdigang address, kaya nahuhulog ito sa loob ng ::/0. Iruta ang buong prefix papasok sa interface at ang mga packet ng handshake ay hahabulin ang sarili nila papasok sa tunel na sinusubukan pa nilang itayo. Hindi kailanman umaangat ang tunel, at walang sinasabi ang output ng kliyente kung bakit.
wg-quick ang humahawak nito sa Linux. Kumukuha ito ng mga ruta mula sa AllowedIPs, ini-install ang mga ito sa sarili nitong talahanayan at nagdaragdag ng patakaran upang ang trapiko patungo sa dulong dulo ay malutas muna sa pangunahing talahanayan: ang tuntuning suppress_prefixlength 0 na makikita mo sa ip -6 rule. Kaya nagtatagumpay ang wg-quick up kung saan ang kamay na isinulat na ip -6 route add default dev wg0 ay pumutol sa iyo.
Suriin ang dalawang estado gamit ang ip -6 route get <endpoint-v6>, bago at pagkatapos iangat ang tunel. Kung ang sagot ay lumipat sa iyong device ng tunel, inalis mo ang landas na kailangan ng tunel. Kapag ikaw mismo ang nagsusulat ng mga ruta, magdagdag ng ruta ng host patungo sa dulong dulo sa pamamagitan ng orihinal na gateway, o kumonekta sa dulong dulo sa IPv4 at iwanan ang IPv6 sa payload.
Ano ang dapat manatili sa labas ng tunel?
Ang mas tiyak na ruta ay nananalo sa default, kaya ang prefix sa link o saklaw ng ULA na may sariling ruta ay patuloy na gumagana nang walang dagdag na pagsisikap. Ito ang tahimik na dahilan kung bakit napakaraming IPv4 setup na buong tunel ang nakakaligtas: ang mga prefix ng LAN ay mas tiyak kaysa sa default at hindi kailanman pumapasok sa tunel.
Nasira ito kapag ang lokal na device ay naaabot sa pamamagitan ng pandaigdigang address, na normal para sa printer na binigyan ng pampublikong prefix ng parehong router, isang NAS o isang telebisyon. Ang mga address na iyon ay tumutugma sa ::/0 at wala nang iba, kaya lumilipat sila papasok sa tunel kasama ng lahat ng iba at nawawala.
Magpasya ayon sa destinasyon, hindi ayon sa protocol. Kung mahalaga ang dalawa o tatlong lokal na host, bigyan ang kanilang mga prefix ng rutang palabas sa pisikal na interface, o alisin sila sa napagkasunduang set. Kung patuloy na lumalaki ang listahan, ang tapat na sagot ay split tunneling para sa IPv6 na may nakasulat na listahan ng eksepsiyon, hindi isang default na patuloy mong tinatapalan.
Kung ang sagot ay hindi, harangin ito
Ang iwanan ang IPv6 na walang ruta ay hindi katulad ng iwanan ito nang payapa. Ang host na may gumaganang default na IPv6 ay patuloy na gumagamit nito habang nagdadala ng IPv4 ang tunel, kaya lumalabas ang trapiko sa tabi ng VPN at bawat serbisyong mas gusto ang IPv6 ay nakikita ang iyong tunay na address. Iyon ay pagtagas, hindi split tunnel.
Pumili ng isa at isulat kung alin ang pinili mo. Iruta ang default at tanggapin ang mga trade-off sa itaas, o i-disable ang IPv6 habang tumatagal ang tunel. Ang pag-alis ng prefix mula sa AllowedIPs ay hindi sapat nang mag-isa, dahil pinapanatili ng operating system ang sarili nitong default. Sa Linux ang bastos na bersyon ay sysctl -w net.ipv6.conf.all.disable_ipv6=1; ang mas pinong bersyon ay nagtatapon ng IPv6 sa labas ng tunel gamit ang tuntunin ng firewall. Ang mga kliyente ng telepono ay may tahasang toggle na humaharang sa IPv6 na gumagawa ng parehong trabaho.
I-verify ito na parang pagtagas
Iangat ang tunel at basahin ang estado sa halip na magtiwala sa toggle. Dapat magpakita ang ip -6 route show default ng isang default, at dapat banggitin ng ip -6 route get ang device ng tunel para sa destinasyong labas ng iyong LAN. Ulitin ang dalawa pagkatapos ng pagkadiskonekta: ang default na nabubuhay nang mas matagal kaysa sa tunel ang bug na hinahanap mo.
Pagkatapos ay subukan ang kabilang direksyon. Mula sa host sa lokal na network, maabot ang kliyente sa lokal nitong address na IPv6. Kung tumigil itong gumana, hindi kailanman natupad ang ikatlong kondisyon, anuman ang sinabi ng talahanayan ng ruta noon.
Isulat ang resulta kung saan ito hahanapin ng susunod na tao: aling mga prefix ang nananatiling lokal, bakit, at ano ang ginagawa ng kliyente pagkatapos ng pagkadiskonekta. Dalawang linya sa runbook ang nagliligtas sa susunod na inhinyero mula sa muling pagtuklas ng loop ng dulong dulo sa hatinggabi.