Núdzový vypínač blokuje len IPv4: prečo IPv6 stále uniká

Tunel spadne, núdzový vypínač hlási, že sa aktivoval, a sťahovanie pokračuje. Na pravidlách IPv4 nič nie je pokazené. Aplikácia sa jednoducho presunula na cestu, pre ktorú tieto pravidlá nikdy neboli napísané.

Zariadenia s duálnym zásobníkom majú dve nezávislé cesty von. Blokovanie jednej z nich je polovičné blokovanie.

Dve sady pravidiel, dve predvolené hodnoty

V Linuxe sú iptables a ip6tables samostatné tabuľky so samostatnými politikami. Nastavenie reťazcov INPUT a OUTPUT tabuľky IPv4 na DROP nič nemení v tabuľke IPv6, kde je predvolená hodnota zvyčajne ACCEPT. Rovnaké rozdelenie existuje v nftables, kde môžete preskúmať jednu rodinu a zistiť, že vaše pravidlá nesie len jedna z nich. Táto asymetria je normálna a celý problém je práve v nej.

Preto môže núdzový vypínač vyzerať dôkladne a správať sa čiastočne. Skript, ktorý zapísal pravidlá IPv4, prebehol, počítadlá rastú, riadok v logu sa objaví a paket IPv6 odchádza fyzickým rozhraním úplne nedotknutý.

Čítajte, čo váš klient skutočne inštaluje, a nie čo sľubuje marketingová stránka. Niektorí klienti smerujú IPv6 do tunela, iní ho zámerne blokujú a ďalší ho nechávajú tak, kým uzamknutie na úrovni platformy uplatňuje iné pravidlo. Dokumentácia výrobcu je tu jediný zdroj, ktorému sa oplatí veriť.

Čo vám hovorí konfigurácia rozhrania

Stránka manuálu wg-quick obsahuje pravidlá IPv6 v ukážkovej konfigurácii a dôvodom je presne táto medzera. Ukážka nie je dekorácia. Existuje preto, že samotné pravidlá IPv4 by nechali druhú rodinu otvorenú.

Kopírovanie polovice ukážky produkuje polovicu politiky. To je najčastejší pôvod tohto úniku. Blogový príspevok ukážku skrátil kvôli dĺžke. Skrátená verzia sa potom stala šablónou, ktorú všetci znova 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

Ak druhý príkaz vypisuje povoľujúcu politiku, zatiaľ čo prvý vypisuje DROP, našli ste odpoveď bez toho, aby ste sa dotkli klienta. Táto asymetria je tá chyba.

Prečo jeden dopyt nie je celý príbeh

Jeden názov môže vrátiť záznam A aj záznam AAAA a aplikácie nevyberajú všetky rovnako. Prehliadač môže uprednostniť IPv6, keď ho sieť ponúka, a pri zlyhaní sa vrátiť, zatiaľ čo synchronizácia na pozadí alebo aktualizátor používa vlastný resolver a vlastnú preferenciu. Jeden úspešný test cez IPv4 teda dokazuje jednu cestu, nie politiku.

Prechody medzi sieťami menia aj odpoveď. Pripojenie k inej sieti Wi-Fi, prebudenie zo spánku alebo prechod na mobilnú sieť môže zariadeniu dať nový prefix IPv6 a politika, ktorá vyzerala dostatočne v kancelárskej LAN, ho nemusí pokrývať.

Otestujte stav, keď je tunel vypnutý

Testovanie pripojenia vám povie, že tunel funguje. Zaujímavý test je nedostupný stav, pretože práve vtedy má núdzový vypínač vydržať. Úmyselne zastavte tunel a potom vyskúšajte dôležité ciele z aplikácie, ktorú chránite.

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

Obe rodiny by mali zlyhať zavreté. Ak požiadavka IPv4 vyprší a požiadavka IPv6 vráti stavový kód, politika je neúplná a žiadne opakované testovanie tunela to nezmení.

V tom teste zachovajte aj zdokumentované výnimky. Zisťovanie lokálnej siete, obnova DHCP alebo zavádzacia cesta ku koncovému bodu VPN môžu potrebovať zostať dostupné a tieto výnimky by mali byť pomenované v politike, namiesto toho, aby boli objavené počas výpadku. Test úniku, ktorý zlyhá preto, že sa tunel nemôže vrátiť, nie je bezpečnostné zistenie, je to zistenie o konektivite.