Noodschakelaar blokkeert alleen IPv4: waarom IPv6 er toch uit gaat

De tunnel valt weg, de noodschakelaar meldt dat hij heeft ingegrepen, en een download blijft lopen. Aan de IPv4-regels is niets kapot. De app is simpelweg naar een route verschoven waarvoor die regels nooit zijn geschreven.

Dual-stack-apparaten hebben twee onafhankelijke uitgangen. Een blokkade op een van beide is een halve blokkade.

Twee regelsets, twee standaardwaarden

Op Linux zijn iptables en ip6tables aparte tabellen met aparte policies. Het instellen van de INPUT- en OUTPUT-ketens van de IPv4-tabel op DROP verandert niets in de IPv6-tabel, waar de standaard meestal ACCEPT is. Dezelfde splitsing bestaat in nftables, waar je één familie kunt inspecteren en ontdekt dat slechts één ervan jouw regels draagt. Die asymmetrie is normaal, en het is het hele probleem.

Daarom kan een noodschakelaar grondig lijken en zich gedeeltelijk gedragen. Het script dat de IPv4-regels schreef, liep, de tellers lopen op, de logregel verschijnt, en een IPv6-pakket verlaat de fysieke interface volledig onaangetast.

Lees wat je client werkelijk installeert in plaats van wat de marketingpagina belooft. Sommige clients routeren IPv6 de tunnel in, sommige blokkeren het bewust, en sommige laten het met rust terwijl een vergrendeling op platformniveau een andere regel afdwingt. De documentatie van de leverancier is hier de enige bron die het vertrouwen waard is.

Wat de interfaceconfiguratie je vertelt

De handleidingspagina van wg-quick bevat IPv6-regels in de voorbeeldconfiguratie, en de reden is precies deze kloof. Het voorbeeld is geen versiering. Het bestaat omdat alleen de IPv4-regels de tweede familie open zouden laten.

De helft van een voorbeeld kopiëren levert de helft van een beleid op. Dat is de meest voorkomende oorsprong van deze lek. Een blogpost kortte het voorbeeld in vanwege de lengte. De ingekorte versie werd vervolgens de sjabloon die iedereen hergebruikte.

# 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

Als de tweede opdracht een toestaand beleid afdrukt terwijl de eerste DROP afdrukt, heb je het antwoord gevonden zonder de client aan te raken. Die asymmetrie is de bug.

Waarom één opzoeking niet het hele verhaal is

Eén naam kan zowel een A-record als een AAAA-record teruggeven, en applicaties kiezen niet allemaal hetzelfde. Een browser kan IPv6 verkiezen wanneer het netwerk het biedt en bij een fout terugvallen, terwijl een achtergrondsynchronisatie of een updater zijn eigen resolver en zijn eigen voorkeur gebruikt. Eén geslaagde test over IPv4 bewijst daarom één route, niet het beleid.

Netwerkwisselingen veranderen het antwoord ook. Verbinden met een ander Wi-Fi-netwerk, uit de slaapstand komen of overschakelen naar mobiel kan het apparaat een nieuw IPv6-prefix geven, en het beleid dat op de kantoor-LAN toereikend leek, dekt het misschien niet.

Test de toestand waarin de tunnel uit staat

Testen terwijl je verbonden bent, zegt je dat de tunnel werkt. De interessante test is de niet-beschikbare toestand, want dan hoort de noodschakelaar te houden. Stop de tunnel expres, en probeer daarna de bestemmingen die ertoe doen vanuit de app die je beschermt.

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

Beide families zouden gesloten moeten falen. Als het IPv4-verzoek een time-out krijgt en het IPv6-verzoek een statuscode teruggeeft, is het beleid onvolledig, en geen enkele hoeveelheid opnieuw testen van de tunnel verandert dat.

Houd ook de gedocumenteerde uitzonderingen in die test. Lokale netwerkontdekking, een DHCP-vernieuwing of het bootstrap-pad naar het VPN-eindpunt kunnen bereikbaar moeten blijven, en die uitzonderingen zouden in het beleid genoemd moeten worden in plaats van ontdekt te worden tijdens een storing. Een lektest die faalt omdat de tunnel niet terug kan komen, is geen beveiligingsbevinding, het is een connectiviteitsbevinding.