Skal vi slå IPv6 fra for at rette en VPN-lækage? Beslut politikken i stedet

En adresse fra IPv6-området dukker op på en testside, tunnelen bærer den tydeligvis ikke, og internettets mest populære råd er at slå IPv6 fra overalt. Den kommando får da også panelet til at tie. Den fjerner samtidig en protokol, som adgangsnettet kan afhænge af, og den efterlader dig uden anelse om, hvorvidt adressen var en rigtig lækage, en link-local-grænsefladeadresse eller en resolver, der gør sit arbejde. Tre betingelser afgør den rigtige kontrol, og kun én af dem fører til blokering.

Find ud af, hvad værktøjet faktisk målte

Den mest almindelige falske alarm er en link-local-adresse, som begynder med fe80: og findes på enhver IPv6-kompatibel grænseflade, uanset om maskinen kan nå internettet over IPv6. Den optræder i grænsefladelister og i nogle programdiagnostikker og siger intet om din trafikvej.

Den anden falske alarm er en unik lokal adresse i fc00::/7, som er et privat område, der bruges inde i et netværk. Et værktøj, der udskriver enhver adresse, værten har, viser den gerne ved siden af den offentlige. Enhver, der læser hurtigt, kalder det en lækage og bruger derefter en time på et problem, der ikke findes.

Den tredje er slet ikke en falsk alarm. En global adresse, der når internettet uden om tunnelen, er den rigtige lækage, og den er værd at måle, før du beslutter noget:

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

Hvis den første kommando udskriver en global adresse, og den tredje returnerer en offentlig IPv6-adresse, som ikke er tunnelens, har du en ægte vej uden om tunnelen. Hvis den første ikke udskriver andet end link-local-poster, har der aldrig været en lækage at rette.

Tre betingelser afgør kontrollen

Beslutningen er ikke "IPv6 god" eller "IPv6 dårlig". Det er, hvilken af tre situationer du er i, og hver har et forskelligt rigtigt svar med en forskellig pris, hvis du tager fejl.

Den første række er det, folk normalt mener, og den er legitim. En klient, hvis udgang ikke understøtter IPv6, bør ikke i stilhed lade værtens egen IPv6-trafik gå ud, for det er den dokumenterede dual-stack-lækage. Pointen er at blokere det som en erklæret politik, ikke at slå en protokol fra i kernen. Det synlige resultat er identisk, og kun det ene kan gennemgås senere.

Den tredje række er, hvor det generelle råd bliver aktivt skadeligt. Mobiloperatører og nogle hjemmeforbindelser kører IPv6-only-netværk med oversættelse for IPv4-destinationer. Fjern IPv6 der, og du fjerner den eneste transport, netværket tilbyder, hvilket giver et meget værre udfald end det, du fejlrettede.

Hvis udgangen ikke har IPv6, bloker den med vilje

Foretræk klientens egen mekanisme, fordi den gælder præcis, mens tunnelen er oppe, og går tilbage, når den falder. OpenVPN har en indstilling til dette, og iptables har en tilsvarende regel til andre klienter:

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

Direktivet hører i profilen; reglen hører i en firewall, du kan gennemgå og fjerne. Begge fejler lukket, hvilket er det, du vil have, og begge er synlige i en konfigurationsdiff, hvilket en kernel-sysctl begravet i et opstartsscript ikke er.

Skriv ned, hvorfor den er der. En blokeringsregel uden kommentar bliver fjernet af den næste, der har brug for IPv6 til noget andet, og så vender lækagen stille tilbage.

Hvis udgangen bærer IPv6, rut den og test begge familier

At bære IPv6 er det bedre svar, når serveren understøtter det, og det er ikke meget sværere. Kravet er, at tunnelgrænsefladen har en adresse i den familie, og at standardruten for den peger ind i tunnelen frem for ud af den fysiske grænseflade:

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

Ruteopslaget er den afgørende test: hvis det navngiver tunnelgrænsefladen, bliver IPv6-trafik båret. De to curl-kald bekræfter derefter, hvad hver familie ser, og at sammenligne dem er måden at bevise, at begge veje nu forlader samme udgang.

Stop ikke ved en vellykket forbindelse. Genopret tunnelen, og kontrollér igen, fordi en skubbet IPv6-rute kan gå tabt ved genetablering, hvis serveren kun sender den i den første konfiguration. Kontrollér derefter én udelukket destination, fordi split-tunnel-regler er der, hvor de to familier oftest er uenige.

Hvis adgangsnettet kun er IPv6, så lad det være

Nogle netværk leverer kun IPv6 og forventer, at enheden når IPv4-tjenester gennem en oversættelsesmekanisme på operatørens side. At slå IPv6 fra på en sådan maskine er ikke en sikkerhedsforbedring; det fjerner den eneste rute til noget som helst. Det er et selvforvoldt udfald til ære for et testresultat, som ingen havde brug for.

Symptomet på at gøre dette forkert er umiskendeligt og ubehageligt: tunnelen ser ud til at etablere, navneopløsning virker, og intet indlæses. Hvis du ser det efter en IPv6-ændring, gendan indstillingen med det samme, og fortsæt diagnosticeringen et andet sted.

Uanset hvad du vælger, så hold beslutningen eksplicit i profilen eller firewallen, bind den til det, udgangen faktisk understøtter, og notér den dual-stack-adfærd, som RFC 7359-diskussionen om dual stack beskriver. En erklæret blokering er en politik. En slået fra protokol er en omvej, som ingen kan revidere, og de ser identiske ud fra testsiden.