Skal vi slå av IPv6 for å fikse en VPN-lekkasje? Bestem policyen i stedet

En adresse fra IPv6-området dukker opp på en testside, tunnelen bærer den tydeligvis ikke, og internettets mest populære råd er å slå av IPv6 overalt. Den kommandoen får panelet til å tie. Den fjerner også en protokoll som aksessnettet kan være avhengig av, og den lar deg stå uten anelse om adressen var en ekte lekkasje, en link-local-grensesnittadresse eller en resolver som gjør jobben sin. Tre betingelser avgjør riktig kontroll, og bare én av dem fører til blokkering.

Finn ut hva verktøyet faktisk målte

Den vanligste falske alarmen er en link-local-adresse, som begynner med fe80: og finnes på hvert IPv6-kompatible grensesnitt, uansett om maskinen når internett over IPv6 eller ikke. Den dukker opp i grensesnittlister og i noen programdiagnostikker, og sier ingenting om trafikkveien din.

Den andre falske alarmen er en unik lokal adresse i fc00::/7, som er et privat område brukt inne i et nettverk. Et verktøy som skriver ut hver adresse verten har, viser den gjerne ved siden av den offentlige. Den som leser raskt, kaller det en lekkasje og bruker deretter en time på et problem som ikke finnes.

Den tredje er slett ikke en falsk alarm. En global adresse som når internett utenfor tunnelen, er den ekte lekkasjen, og den er verdt å måle før du bestemmer noe:

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

Hvis den første kommandoen skriver ut en global adresse og den tredje returnerer en offentlig IPv6-adresse som ikke er tunnelens, har du en reell vei utenfor tunnelen. Hvis den første ikke skriver ut annet enn link-local-oppføringer, har det aldri vært en lekkasje å fikse.

Tre betingelser avgjør kontrollen

Beslutningen er ikke "IPv6 bra" eller "IPv6 dårlig". Det er hvilken av tre situasjoner du er i, og hver har et annet riktig svar med en annen kostnad hvis du tar feil.

Den første raden er det folk vanligvis mener, og den er legitim. En klient hvis utgang ikke støtter IPv6, bør ikke i stillhet slippe vertens egen IPv6-trafikk ut, for det er den dokumenterte dual-stack-lekkasjen. Poenget er å blokkere det som en erklært policy, ikke å slå av en protokoll i kjernen. Det synlige resultatet er identisk, og bare ett av dem kan gjennomgås senere.

Den tredje raden er der det generelle rådet blir aktivt skadelig. Mobiloperatører og noen hjemmeforbindelser kjører IPv6-only-nettverk med oversettelse for IPv4-destinasjoner. Fjern IPv6 der, og du fjerner den eneste transporten nettverket tilbyr, noe som gir et mye verre avbrudd enn det du feilsøkte.

Hvis utgangen ikke har IPv6, blokker den med vilje

Foretrekk klientens egen mekanisme, fordi den gjelder nøyaktig mens tunnelen er oppe og går tilbake når den faller. OpenVPN har et alternativ for dette, og iptables har en tilsvarende regel for andre klienter:

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

Direktivet hører hjemme i profilen; regelen hører hjemme i en brannmur du kan gjennomgå og fjerne. Begge feiler lukket, som er det du vil, og begge er synlige i en konfigurasjonsdiff, noe en kjerne-sysctl begravd i et oppstartsskript ikke er.

Skriv ned hvorfor den er der. En blokkeringsregel uten kommentar blir fjernet av den neste som trenger IPv6 til noe annet, og så kommer lekkasjen stille tilbake.

Hvis utgangen bærer IPv6, rut det og test begge familier

Å bære IPv6 er det bedre svaret når serveren støtter det, og det er ikke mye vanskeligere. Kravet er at tunnelgrensesnittet har en adresse i den familien, og at standardruten for den peker inn i tunnelen og ikke ut av det fysiske grensesnittet:

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

Ruteoppslaget er den avgjørende testen: hvis det navngir tunnelgrensesnittet, blir IPv6-trafikk båret. De to curl-kallene bekrefter deretter hva hver familie ser, og å sammenligne dem er måten å bevise at begge veiene nå forlater samme utgang.

Ikke stopp ved en vellykket tilkobling. Koble tunnelen på nytt og kontroller igjen, fordi en dyttet IPv6-rute kan gå tapt ved gjenoppretting hvis serveren bare sender den i den første konfigurasjonen. Kontroller deretter én utelukket destinasjon, fordi split-tunnel-regler er der de to familiene oftest er uenige.

Hvis aksessnettet bare er IPv6, la det være

Noen nettverk leverer bare IPv6 og forventer at enheten når IPv4-tjenester gjennom en oversettelsesmekanisme på operatørens side. Å slå av IPv6 på en slik maskin er ikke en sikkerhetsforbedring; det fjerner den eneste veien til noe som helst. Det er et selvpåført avbrudd til ære for et testresultat ingen trengte.

Symptomet på å gjøre dette feil er umiskjennelig og ubehagelig: tunnelen ser ut til å etablere seg, navneoppslag virker, og ingenting lastes. Hvis du ser det etter en IPv6-endring, gjenopprett innstillingen umiddelbart og fortsett diagnostikken et annet sted.

Uansett hva du velger, hold beslutningen eksplisitt i profilen eller brannmuren, bind den til det utgangen faktisk støtter, og noter dual-stack-atferden som RFC 7359-diskusjonen om dual stack beskriver. En erklært blokkering er en policy. En avslått protokoll er en omvei ingen kan revidere, og fra testsiden ser de identiske ut.