Nødstoppar blokkerer berre IPv4: kvifor IPv6 likevel slepp ut

Tunnelen fell, nødstopparen rapporterer at han har slått inn, og ei nedlasting held fram. Ingenting er øydelagt i IPv4-reglane. Appen flytta seg rett og slett til ein veg som desse reglane aldri vart skrivne for.

Einingar med dobbel stakk har to uavhengige vegar ut. Ei blokkering på éin av dei er ei halv blokkering.

To regelsett, to standardverdiar

På Linux er iptables og ip6tables separate tabellar med separate retningslinjer. Å setje INPUT- og OUTPUT-kjedene i IPv4-tabellen til DROP endrar ingenting i IPv6-tabellen, der standardverdien vanlegvis er ACCEPT. Den same delinga finst i nftables, der du kan undersøkje éin familie og oppdage at berre éin av dei ber reglane dine. Den asymmetrien er normal, og det er heile problemet.

Derfor kan ein nødstoppar sjå grundig ut og oppføre seg delvis. Skriptet som skreiv IPv4-reglane, køyrde, teljarane aukar, logglinja viser seg, og ein IPv6-pakke forlèt det fysiske grensesnittet heilt urørt.

Les kva klienten din faktisk installerer, i staden for kva marknadsføringssida lovar. Nokre klientar ruter IPv6 inn i tunnelen, nokre blokkerer det med vilje, og nokre lèt det vere medan ein lås på plattformnivå handhevar ein annan regel. Dokumentasjonen frå leverandøren er den einaste kjelda som er verdt å stole på her.

Kva grensesnittkonfigurasjonen fortel deg

Manualsida til wg-quick inkluderer IPv6-reglar i eksempelkonfigurasjonen sin, og årsaka er nøyaktig dette gapet. Eksempelet er ikkje pynt. Det finst fordi berre IPv4-reglane ville late den andre familien stå open.

Å kopiere halvparten av eit eksempel gir halvparten av ein retningslinje. Det er den vanlegaste opphavet til denne lekkasjen. Eit blogginnlegg forkorta eksempelet av omsyn til lengda. Den forkorta versjonen vart 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

Viss den andre kommandoen skriv ut ein tillatande retningslinje medan den første skriv ut DROP, har du funne svaret utan å røre klienten. Den asymmetrien er feilen.

Kvifor eitt oppslag ikkje er heile historia

Eitt namn kan returnere både ein A-post og ein AAAA-post, og applikasjonar vel ikkje alle på same måte. Ein nettlesar kan føretrekkje IPv6 når nettverket tilbyr det, og falle tilbake ved feil, medan ein bakgrunnssynkronisering eller oppdatering brukar sin eigen resolver og sin eigen preferanse. Ein vellukka test over IPv4 beviser derfor éin veg, ikkje retningslinja.

Nettverksovergangar endrar også svaret. Å kople seg til eit anna Wi-Fi-nettverk, vakne frå dvale eller byte til mobilnett kan gi eininga eit nytt IPv6-prefiks, og retningslinja som såg tilstrekkeleg ut på kontoret sitt LAN, dekkjer det kanskje ikkje.

Test tilstanden der tunnelen er nede

Testing medan du er tilkopla fortel deg at tunnelen verkar. Den interessante testen er den utilgjengelege tilstanden, for det er då nødstopparen skal halde. Stopp tunnelen med vilje, og prøv deretter destinasjonane som betyr noko, frå appen du vernar.

# 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 familiane bør feile lukka. Viss IPv4-førespurnaden får tidsavbrot og IPv6-førespurnaden returnerer ein statuskode, er retningslinja ufullstendig, og inga mengd ny testing av tunnelen vil endre det.

Hald også dei dokumenterte unntaka i den testen. Lokal nettverksoppdaging, ei DHCP-fornying eller oppstartsvegen til VPN-endepunktet kan trenge å halde fram med å vere tilgjengeleg, og desse unntaka bør namngivast i retningslinja i staden for å bli oppdaga under eit avbrot. Ein lekkasjetest som feilar fordi tunnelen ikkje kan kome opp att, er ikkje eit sikkerheitsfunn, det er eit tilkoplingfunn.