Nødstopper blokkerer bare IPv4: hvorfor IPv6 likevel slipper ut

Tunnelen faller, nødstopperen rapporterer at den har slått inn, og en nedlasting fortsetter. Ingenting er ødelagt i IPv4-reglene. Appen flyttet seg rett og slett til en vei som disse reglene aldri ble skrevet for.

Enheter med dobbel stakk har to uavhengige veier ut. En blokkering på én av dem er en halv blokkering.

To regelsett, to standardverdier

På Linux er iptables og ip6tables separate tabeller med separate retningslinjer. Å sette INPUT- og OUTPUT-kjedene i IPv4-tabellen til DROP endrer ingenting i IPv6-tabellen, der standardverdien vanligvis er ACCEPT. Den samme delingen finnes i nftables, der du kan undersøke én familie og oppdage at bare én av dem bærer reglene dine. Den asymmetrien er normal, og det er hele problemet.

Derfor kan en nødstopper se grundig ut og oppføre seg delvis. Skriptet som skrev IPv4-reglene, kjørte, tellerne øker, logglinjen vises, og en IPv6-pakke forlater det fysiske grensesnittet helt urørt.

Les hva klienten din faktisk installerer, i stedet for hva markedsføringssiden lover. Noen klienter ruter IPv6 inn i tunnelen, noen blokkerer det bevisst, og noen lar det være mens en lås på plattformnivå håndhever en annen regel. Leverandørens dokumentasjon er den eneste kilden som er verdt å stole på her.

Hva grensesnittkonfigurasjonen forteller deg

Manualsiden til wg-quick inkluderer IPv6-regler i eksempelkonfigurasjonen sin, og årsaken er nøyaktig dette gapet. Eksempelet er ikke pynt. Det finnes fordi bare IPv4-reglene ville la den andre familien stå åpen.

Å kopiere halvparten av et eksempel gir halvparten av en retningslinje. Det er den vanligste opprinnelsen til denne lekkasjen. Et blogginnlegg forkortet eksempelet av lengdehensyn. Den forkortede versjonen ble deretter malen alle brukte på nytt.

# 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 andre kommandoen skriver ut en tillatende retningslinje mens den første skriver ut DROP, har du funnet svaret uten å røre klienten. Den asymmetrien er feilen.

Hvorfor ett oppslag ikke er hele historien

Ett navn kan returnere både en A-post og en AAAA-post, og applikasjoner velger ikke alle på samme måte. En nettleser kan foretrekke IPv6 når nettverket tilbyr det, og falle tilbake ved feil, mens en bakgrunnssynkronisering eller oppdatering bruker sin egen resolver og sin egen preferanse. En vellykket test over IPv4 beviser derfor én vei, ikke retningslinjen.

Nettverksoverganger endrer også svaret. Å koble seg til et annet Wi-Fi-nettverk, våkne fra dvale eller bytte til mobilnett kan gi enheten et nytt IPv6-prefiks, og retningslinjen som så tilstrekkelig ut på kontorets LAN, dekker det kanskje ikke.

Test tilstanden der tunnelen er nede

Testing mens du er tilkoblet forteller deg at tunnelen virker. Den interessante testen er den utilgjengelige tilstanden, for det er da nødstopperen skal holde. Stopp tunnelen med vilje, og prøv deretter destinasjonene som betyr noe, fra appen 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 familiene bør feile lukket. Hvis IPv4-forespørselen får tidsavbrudd og IPv6-forespørselen returnerer en statuskode, er retningslinjen ufullstendig, og ingen mengde ny testing av tunnelen vil endre det.

Behold også de dokumenterte unntakene i den testen. Lokal nettverksoppdagelse, en DHCP-fornyelse eller oppstartsveien til VPN-endepunktet kan trenge å forbli tilgjengelig, og disse unntakene bør navngis i retningslinjen i stedet for å bli oppdaget under et avbrudd. En lekkasjetest som feiler fordi tunnelen ikke kan komme opp igjen, er ikke et sikkerhetsfunn, det er et tilkoblingsfunn.