Nödstopp blockerar bara IPv4: varför IPv6 ändå läcker ut

Tunneln faller, nödstoppet rapporterar att det har slagit till, och en nedladdning fortsätter. Ingenting är trasigt i IPv4-reglerna. Appen flyttade helt enkelt till en väg som dessa regler aldrig skrevs för.

Enheter med dubbel stack har två oberoende vägar ut. En blockering på en av dem är en halv blockering.

Två regeluppsättningar, två standardvärden

På Linux är iptables och ip6tables separata tabeller med separata policyer. Att sätta INPUT- och OUTPUT-kedjorna i IPv4-tabellen till DROP ändrar ingenting i IPv6-tabellen, där standardvärdet vanligtvis är ACCEPT. Samma uppdelning finns i nftables, där du kan undersöka en familj och upptäcka att bara en av dem bär dina regler. Den asymmetrin är normal, och det är hela problemet.

Därför kan ett nödstopp se grundligt ut och bete sig delvis. Skriptet som skrev IPv4-reglerna kördes, räknarna ökar, loggrader visas, och ett IPv6-paket lämnar det fysiska gränssnittet helt orört.

Läs vad din klient faktiskt installerar i stället för vad marknadsföringssidan lovar. Vissa klienter dirigerar IPv6 in i tunneln, andra blockerar det medvetet, och andra lämnar det ifred medan ett lås på plattformsnivå tillämpar en annan regel. Leverantörens dokumentation är den enda källan som är värd att lita på här.

Vad gränssnittskonfigurationen berättar för dig

Manualsidan för wg-quick innehåller IPv6-regler i sin exempelkonfiguration, och orsaken är precis denna lucka. Exemplet är inte dekoration. Det finns eftersom bara IPv4-reglerna skulle lämna den andra familjen öppen.

Att kopiera halva exemplet ger halva policyn. Det är det vanligaste ursprunget till denna läcka. Ett blogginlägg kortade exemplet av längdskäl. Den kortade versionen blev sedan mallen som alla återanvände.

# 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

Om det andra kommandot skriver ut en tillåtande policy medan det första skriver ut DROP, har du hittat svaret utan att röra klienten. Den asymmetrin är buggen.

Varför en enda uppslagning inte är hela historien

Ett enda namn kan returnera både en A-post och en AAAA-post, och applikationer väljer inte alla på samma sätt. En webbläsare kan föredra IPv6 när nätverket erbjuder det och falla tillbaka vid fel, medan en bakgrundssynkronisering eller uppdaterare använder sin egen resolver och sin egen preferens. En lyckad test över IPv4 bevisar därför en väg, inte policyn.

Nätverksväxlingar ändrar också svaret. Att ansluta till ett annat Wi-Fi-nätverk, vakna ur viloläge eller byta till mobilnät kan ge enheten ett nytt IPv6-prefix, och policyn som verkade tillräcklig på kontorets LAN täcker det kanske inte.

Testa tillståndet där tunneln är nere

Att testa medan du är ansluten säger att tunneln fungerar. Det intressanta testet är det otillgängliga tillståndet, för det är då nödstoppet ska hålla. Stoppa tunneln med avsikt och prova sedan destinationerna som spelar roll från appen du skyddar.

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

Båda familjerna bör misslyckas stängda. Om IPv4-begäran får timeout och IPv6-begäran returnerar en statuskod är policyn ofullständig, och ingen mängd ny testning av tunneln ändrar det.

Behåll också de dokumenterade undantagen i det testet. Lokal nätverksupptäckt, en DHCP-förnyelse eller startvägen till VPN-slutpunkten kan behöva förbli nåbar, och dessa undantag bör namnges i policyn i stället för att upptäckas under ett avbrott. Ett läckagetest som misslyckas för att tunneln inte kan komma upp igen är inte ett säkerhetsfynd, det är ett anslutningsfynd.