Nødafbryder blokerer kun IPv4: hvorfor IPv6 stadig slipper ud

Tunnelen falder, nødafbryderen rapporterer, at den er slået til, og en download kører videre. Intet er i stykker i IPv4-reglerne. Appen er blot flyttet til en vej, som disse regler aldrig blev skrevet til.

Enheder med dobbelt stak har to uafhængige veje ud. En blokering af den ene er en halv blokering.

To regelsæt, to standarder

På Linux er iptables og ip6tables separate tabeller med separate politikker. At sætte INPUT- og OUTPUT-kæderne i IPv4-tabellen til DROP ændrer intet i IPv6-tabellen, hvor standarden normalt er ACCEPT. Den samme opdeling findes i nftables, hvor du kan undersøge en familie og opdage, at kun én af dem bærer dine regler. Den asymmetri er normal, og det er hele problemet.

Det er derfor en nødafbryder kan se grundig ud og opføre sig delvist. Scriptet, der skrev IPv4-reglerne, kørte, tællerne stiger, loglinjen vises, og en IPv6-pakke forlader den fysiske grænseflade helt urørt.

Læs, hvad din klient faktisk installerer, i stedet for hvad marketingsiden lover. Nogle klienter sender IPv6 ind i tunnelen, nogle blokerer det bevidst, og nogle lader det være, mens en lås på platformsniveau håndhæver en anden regel. Leverandørens dokumentation er den eneste kilde, der er værd at stole på her.

Hvad grænsefladekonfigurationen fortæller dig

wg-quicks manualside indeholder IPv6-regler i sin eksempelkonfiguration, og årsagen er præcis dette hul. Eksemplet er ikke pynt. Det findes, fordi IPv4-reglerne alene ville efterlade den anden familie åben.

At kopiere halvdelen af et eksempel giver halvdelen af en politik. Det er den mest almindelige oprindelse til denne lækage. Et blogindlæg forkortede eksemplet af hensyn til længden. Den forkortede version blev derefter den skabelon, alle genbrugte.

# 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

Hvis den anden kommando udskriver en tilladende politik, mens den første udskriver DROP, har du fundet svaret uden at røre klienten. Den asymmetri er fejlen.

Hvorfor et enkelt opslag ikke er hele historien

Et enkelt navn kan returnere både en A-post og en AAAA-post, og applikationer vælger ikke alle på samme måde. En browser kan foretrække IPv6, når netværket tilbyder det, og falde tilbage ved fejl, mens en baggrundssynkronisering eller en opdateringsfunktion bruger sin egen resolver og sin egen præference. Et vellykket test over IPv4 beviser derfor én vej, ikke politikken.

Netværksskift ændrer også svaret. At tilslutte sig et andet Wi-Fi-netværk, genoptage fra dvale eller skifte til mobilnet kan give enheden et nyt IPv6-præfiks, og den politik, der så tilstrækkelig ud på kontorets LAN, dækker måske ikke det.

Test tilstanden, hvor tunnelen er nede

Test, mens du er forbundet, fortæller dig, at tunnelen virker. Den interessante test er den utilgængelige tilstand, for det er der, nødafbryderen skal holde. Stop tunnelen med vilje, og prøv derefter de destinationer, der betyder noget, fra den app, du beskytter.

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

Begge familier bør fejle lukket. Hvis IPv4-anmodningen løber ud, og IPv6-anmodningen returnerer en statuskode, er politikken ufuldstændig, og ingen mængde gentest af tunnelen ændrer det.

Behold også de dokumenterede undtagelser i den test. Lokal netværksopdagelse, en DHCP-fornyelse eller bootstrap-stien til VPN-endepunktet kan have brug for at forblive tilgængelige, og disse undtagelser bør navngives i politikken i stedet for at blive opdaget under et udfald. En lækagetest, der fejler, fordi tunnelen ikke kan komme op igen, er ikke et sikkerhedsfund, det er et forbindelsesfund.