Ang kill switch ay humaharang lamang sa IPv4: bakit lumalabas pa rin ang IPv6

Bumagsak ang tunnel, iniuulat ng kill switch na kumilos ito, at tumutuloy ang isang download. Walang sira sa mga patakaran ng IPv4. Lumipat lang ang app sa isang landas na hindi kailanman isinulat ng mga patakarang iyon.

Ang mga dual-stack na device ay may dalawang malayang labasan. Ang harang sa isa sa kanila ay kalahating harang.

Dalawang set ng patakaran, dalawang default

Sa Linux, ang iptables at ip6tables ay magkahiwalay na talahanayan na may magkahiwalay na patakaran. Ang pagtatakda ng INPUT at OUTPUT chain ng talahanayang IPv4 sa DROP ay walang binabago sa talahanayang IPv6, kung saan ang default ay karaniwang ACCEPT. Umiiral din ang parehong paghahati sa nftables, kung saan maaari mong suriin ang isang pamilya at tuklasin na isa lamang sa kanila ang nagdadala ng iyong mga patakaran. Normal ang asimetrikong iyon, at iyon ang buong problema.

Kaya naman ang isang kill switch ay maaaring magmukhang lubusan ngunit kumilos nang bahagya. Ang script na nagsulat ng mga patakaran ng IPv4 ay tumakbo, tumataas ang mga counter, lumilitaw ang log line, at ang isang packet ng IPv6 ay lumalabas sa pisikal na interface nang ganap na hindi nagalaw.

Basahin kung ano ang aktuwal na ini-install ng iyong client, hindi kung ano ang ipinapangako ng pahina ng marketing. Ang ilang client ay nagruruta ng IPv6 papasok sa tunnel, ang iba ay sadyang humaharang dito, at ang iba ay hinahayaan ito habang ang pag-lock sa antas ng platform ay nagpapatupad ng ibang patakaran. Ang dokumentasyon ng vendor ang tanging pinagkakatiwalaang pinagmulan dito.

Ano ang sinasabi sa iyo ng configuration ng interface

Ang pahina ng manwal ng wg-quick ay may kasamang mga patakaran ng IPv6 sa halimbawang configuration nito, at ang dahilan ay eksaktong puwang na ito. Ang halimbawa ay hindi dekorasyon. Umiiral ito dahil ang mga patakaran ng IPv4 lamang ay mag-iiwan sa ikalawang pamilya na bukas.

Ang pagkopya ng kalahati ng isang halimbawa ay gumagawa ng kalahati ng isang patakaran. Ito ang pinakakaraniwang pinagmulan ng pagtagas na ito. Pinaikli ng isang post sa blog ang halimbawa dahil sa haba. Ang pinaikling bersyon ay naging template na muling ginamit ng lahat.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Kung ang pangalawang command ay nagpi-print ng permissive na patakaran habang ang una ay nagpi-print ng DROP, natagpuan mo ang sagot nang hindi hinahawakan ang client. Ang asimetrikong iyon ang bug.

Bakit ang isang paghahanap ay hindi ang buong kuwento

Ang isang pangalan ay maaaring magbalik ng parehong A record at AAAA record, at hindi lahat ng app ay pumipili sa parehong paraan. Maaaring mas gusto ng browser ang IPv6 kapag inaalok ito ng network at bumalik kapag nabigo, habang ang background sync o updater ay gumagamit ng sarili nitong resolver at sariling kagustuhan. Kaya ang isang matagumpay na pagsubok sa IPv4 ay nagpapatunay ng isang landas, hindi ang patakaran.

Binabago rin ng mga transition ng network ang sagot. Ang pagsali sa ibang Wi-Fi network, paggising mula sa pagtulog, o paglipat sa cellular ay maaaring magbigay sa device ng bagong IPv6 prefix, at ang patakarang mukhang sapat sa LAN ng opisina ay maaaring hindi ito masaklaw.

Subukan ang estado kung saan patay ang tunnel

Ang pagsubok habang konektado ay nagsasabi sa iyo na gumagana ang tunnel. Ang kawili-wiling pagsubok ay ang hindi magagamit na estado, dahil iyon ang panahong dapat kumapit ang kill switch. Itigil ang tunnel nang sinasadya, pagkatapos ay subukan ang mahahalagang patutunguhan mula sa app na pinoprotektahan mo.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Dapat mabigo nang sarado ang parehong pamilya. Kung mag-time out ang kahilingang IPv4 at magbalik ng status code ang kahilingang IPv6, hindi kumpleto ang patakaran, at walang dami ng muling pagsubok sa tunnel ang makakabago niyon.

Panatilihin din ang mga nakadokumentong exception sa pagsubok na iyon. Maaaring kailanganing manatiling maabot ang local network discovery, isang DHCP renewal, o ang bootstrap path patungo sa VPN endpoint, at ang mga exception na iyon ay dapat pangalanan sa patakaran sa halip na matuklasan habang may outage. Ang leak test na nabigo dahil hindi makabalik ang tunnel ay hindi natuklasan sa seguridad, ito ay natuklasan sa konektibidad.