Nouzový vypínač blokuje jen IPv4: proč IPv6 stále uniká

Tunel spadne, nouzový vypínač hlásí, že se aktivoval, a stahování pokračuje. Na pravidlech IPv4 není nic rozbité. Aplikace se prostě přesunula na cestu, pro kterou tato pravidla nikdy nebyla napsána.

Zařízení s duálním zásobníkem mají dvě nezávislé cesty ven. Blokace jedné z nich je poloviční blokace.

Dvě sady pravidel, dva výchozí stavy

V Linuxu jsou iptables a ip6tables samostatné tabulky se samostatnými politikami. Nastavení řetězců INPUT a OUTPUT tabulky IPv4 na DROP nic nemění v tabulce IPv6, kde je výchozí hodnota obvykle ACCEPT. Stejné rozdělení existuje v nftables, kde můžete prozkoumat jednu rodinu a zjistit, že vaše pravidla nese jen jedna z nich. Tato asymetrie je normální a celý problém je právě v ní.

Proto může nouzový vypínač vypadat důkladně a chovat se částečně. Skript, který zapsal pravidla IPv4, proběhl, počítadla rostou, řádek v logu se objeví a paket IPv6 odchází fyzickým rozhraním zcela nedotčen.

Čtěte, co váš klient skutečně instaluje, a ne co slibuje marketingová stránka. Někteří klienti směrují IPv6 do tunelu, někteří ho záměrně blokují a někteří ho nechávají být, zatímco uzamčení na úrovni platformy uplatňuje jiné pravidlo. Dokumentace výrobce je zde jediný zdroj, kterému stojí za to věřit.

Co vám říká konfigurace rozhraní

Stránka manuálu wg-quick zahrnuje pravidla IPv6 ve své ukázkové konfiguraci a důvodem je přesně tato mezera. Ukázka není dekorace. Existuje proto, že samotná pravidla IPv4 by nechala druhou rodinu otevřenou.

Kopírování poloviny ukázky produkuje polovinu politiky. To je nejčastější původ tohoto úniku. Blogový příspěvek ukázku zkrátil kvůli délce. Zkrácená verze se pak stala šablonou, kterou všichni znovu použili.

# 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

Pokud druhý příkaz vypisuje povolující politiku, zatímco první vypisuje DROP, našli jste odpověď, aniž byste se klienta dotkli. Ta asymetrie je ta chyba.

Proč jeden dotaz není celý příběh

Jeden název může vrátit záznam A i záznam AAAA a aplikace nevolí všechny stejně. Prohlížeč může upřednostnit IPv6, když ho síť nabízí, a při selhání se vrátit, zatímco synchronizace na pozadí nebo aktualizátor používá vlastní resolver a vlastní preferenci. Jeden úspěšný test přes IPv4 tedy dokazuje jednu cestu, ne politiku.

Přechody mezi sítěmi odpověď také mění. Připojení k jiné síti Wi-Fi, probuzení ze spánku nebo přechod na mobilní síť může zařízení dát nový prefix IPv6 a politika, která vypadala dostatečně na kancelářské LAN, ho nemusí pokrývat.

Otestujte stav, kdy je tunel vypnutý

Testování při připojení vám řekne, že tunel funguje. Zajímavý test je nedostupný stav, protože právě tehdy má nouzový vypínač vydržet. Úmyslně zastavte tunel a potom vyzkoušejte důležité cíle z aplikace, kterou chráníte.

# 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/

Obě rodiny by měly selhat zavřené. Pokud požadavek IPv4 vyprší a požadavek IPv6 vrátí stavový kód, politika je neúplná a žádné opakované testování tunelu to nezmění.

V tom testu zachovejte i zdokumentované výjimky. Objevování lokální sítě, obnova DHCP nebo zaváděcí cesta ke koncovému bodu VPN mohou potřebovat zůstat dostupné a tyto výjimky by měly být v politice pojmenovány, místo aby byly objeveny během výpadku. Test úniku, který selže proto, že se tunel nemůže vrátit, není bezpečnostní zjištění, je to zjištění o konektivitě.