Skal IPv6-trafik gå gennem VPN eller direkte?

To personer bad mig i sidste måned om modsatte resultater: den ene ville have IPv6 dækket af VPN, den anden ville have kontorets printer til at blive ved med at virke. En enkelt rute ::/0 kan ikke levere begge dele alene. Om den rute hører til inde i tunnelen afhænger af tre betingelser, og den første udelukker den for de fleste kommercielle udgange. Hvis udgangen ikke bærer IPv6, skjuler en standardrute derind din trafik i en tunnel, der ikke har noget sted at sende den hen.

Tre betingelser afgør svaret

Standardruten er én linje, ::/0, og den matcher enhver IPv6-destination uden en mere specifik rute (RFC 4291). Det er nemt at installere den. At beslutte, om du bør, kommer ned til tre betingelser.

Betingelse et: udgangen, du forbinder til, har fungerende IPv6 og er villig til at videresende det. Betingelse to: din klient kan holde en vej til tunnelens endepunkt, som normalt ligger inden for det område, du er ved at route. Betingelse tre: du kan navngive de lokale IPv6-destinationer, der skal blive uden for tunnelen.

Hver betingelse fejler på sin egen måde, og derfor koster gætteri en hel aften. En fejlet betingelse et giver dig tavshed og en rutetabel, der ser rigtig ud. En fejlet betingelse to dræber håndtrykket få sekunder efter, det starter. En fejlet betingelse tre efterlader en fungerende tunnel og en utilfreds kollega ved printeren.

Bærer udgangen faktisk IPv6?

En tunnelgrænseflade med en IPv6-adresse beviser intet om den anden side. Mange kommercielle profiler er kun IPv4 indeni: serveren giver dig en v4-adresse og dropper alt andet. Installer en standard fra AllowedIPs ovenpå, og kernen sender gerne IPv6 ind i en grænseflade, hvis modpart aldrig ser det.

Test fra klienten, mens tunnelen er oppe. ping -6 -c 3 2001:4860:4860::8888 og ip -6 route get 2001:4860:4860::8888 besvarer forskellige spørgsmål: om der kommer et svar tilbage, og hvilken enhed kernen valgte. Når den anden nævner din tunnel, og den første intet returnerer, er problemet udgangen, ikke ruten.

Hvis du selv driver udgangen, kan klienttesten bestå, og vejen ender alligevel blindt. Bekræft net.ipv6.conf.all.forwarding=1 på gatewayen, og at dens firewall accepterer pakker, der videresendes ud af tunnelen. En korrekt routet pakke ind i en udgang, der nægter at videresende, ser fra klientsiden præcis ud som en routingfejl.

Kan klienten beholde sin vej til endepunktet?

Det er den, der fangede mig på en laptop med et IPv6-kun WireGuard-endepunkt. Endepunktets adresse er en almindelig global adresse, så den falder inden for ::/0. Route hele præfikset ind i grænsefladen, og håndtrykspakkerne jager sig selv ind i den tunnel, de stadig prøver at bygge. Tunnelen kommer aldrig op, og intet i klientens output siger hvorfor.

wg-quick håndterer dette på Linux. Det udleder ruter fra AllowedIPs, installerer dem i sin egen tabel og tilføjer en politikregel, så trafik til endepunktet først løses via hovedtabellen: reglen suppress_prefixlength 0, som du finder i ip -6 rule. Derfor lykkes wg-quick up, hvor en håndskrevet ip -6 route add default dev wg0 skærer dig af.

Kontroller begge tilstande med ip -6 route get <endpoint-v6>, før og efter du rejser tunnelen. Hvis svaret ændrer sig til din tunneleenhed, har du fjernet den vej, tunnelen har brug for. Når du selv skriver ruterne, tilføj en værtsrute til endepunktet gennem den oprindelige gateway, eller forbind til endepunktet over IPv4 og lad IPv6 være til nyttelasten.

Hvad skal blive uden for tunnelen?

Mere specifikke ruter slår standarden, så et on-link-præfiks eller et ULA-område med sin egen rute bliver ved med at virke uden ekstra besvær. Det er den stille grund til, at så mange IPv4-opsætninger med fuld tunnel overlever: LAN-præfikserne er mere specifikke end standarden og kommer aldrig ind i tunnelen.

Det bryder, når en lokal enhed kan nås via en global adresse, hvilket er normalt for en printer, der har fået et offentligt præfiks af den samme router, en NAS eller et tv. De adresser matcher ::/0 og intet andet, så de flytter ind i tunnelen sammen med alt andet og forsvinder.

Beslut pr. destination, ikke pr. protokol. Hvis to eller tre lokale værter betyder noget, giv deres præfikser en rute ud gennem den fysiske grænseflade, eller fjern dem fra det forhandlede sæt. Hvis listen bliver ved med at vokse, er det ærlige svar split tunneling til IPv6 med en skriftlig undtagelsesliste, ikke en standard, du bliver ved med at lappe.

Hvis svaret er nej, bloker det

At lade IPv6 være uroutet er ikke det samme som at lade det være i fred. En vært med en fungerende IPv6-standard bliver ved med at bruge den, mens tunnelen bærer IPv4, så trafikken forlader ved siden af VPN, og enhver tjeneste, der foretrækker IPv6, ser din rigtige adresse. Det er en lækage, ikke en split tunnel.

Vælg en, og skriv ned, hvilken du valgte. Route standarden og accepter afvejningerne ovenfor, eller deaktiver IPv6, så længe tunnelen varer. At udelade præfikset fra AllowedIPs er ikke nok i sig selv, fordi operativsystemet holder sin egen standard. På Linux er den grove version sysctl -w net.ipv6.conf.all.disable_ipv6=1; den finere version dropper IPv6 uden for tunnelen med en firewallregel. Telefonklienter leveres med en eksplicit bloker-IPv6-kontakt, der gør det samme.

Verificer det som en lækage

Rejs tunnelen, og læs tilstanden i stedet for at stole på kontakten. ip -6 route show default bør vise én standard, og ip -6 route get for en destination uden for dit LAN bør nævne tunneleenheden. Gentag begge efter en afbrydelse: en standard, der overlever tunnelen, er den fejl, du ledte efter.

Test derefter den anden retning. Fra en vært på det lokale netværk, nå klienten på dens lokale IPv6-adresse. Hvis det holder op med at virke, var betingelse tre aldrig opfyldt, uanset hvad rutetabellen hævdede på det tidspunkt.

Skriv resultatet, hvor den næste person finder det: hvilke præfikser bliver lokale, hvorfor, og hvad klienten gør efter en afbrydelse. To linjer i en runbook sparer den næste ingeniør for at genopdage endepunktsløkken ved midnat.