Bør IPv6-trafikk gå gjennom VPN eller direkte?

To personer ba meg i forrige måned om motsatte resultater: den ene ville at IPv6 skulle dekkes av VPN, den andre ville at kontorprinteren skulle fortsette å virke. Én enkelt rute ::/0 kan ikke levere begge alene. Om den ruten hører til inne i tunnelen avhenger av tre betingelser, og den første utelukker den for de fleste kommersielle utganger. Hvis utgangen ikke bærer IPv6, skjuler rutingen av standardruten dit trafikken din i en tunnel som ikke har noe sted å sende den.

Tre betingelser avgjør svaret

Standardruten er én linje, ::/0, og den passer til enhver IPv6-destinasjon uten en mer spesifikk rute (RFC 4291). Det er enkelt å installere den. Å avgjøre om du bør, koker ned til tre betingelser.

Betingelse én: utgangen du kobler til, har fungerende IPv6 og er villig til å videresende det. Betingelse to: klienten din kan holde en vei til tunnelens endepunkt, som vanligvis ligger innenfor området du er i ferd med å rute. Betingelse tre: du kan navngi de lokale IPv6-destinasjonene som må holde seg utenfor tunnelen.

Hver betingelse feiler på sin måte, og derfor koster gjetting en hel kveld. En feilet betingelse én gir deg stillhet og en rutetabell som ser riktig ut. En feilet betingelse to dreper håndtrykket noen sekunder etter at det starter. En feilet betingelse tre etterlater en fungerende tunnel og en misfornøyd kollega ved printeren.

Bærer utgangen faktisk IPv6?

Et tunellgrensesnitt med en IPv6-adresse beviser ingenting om den andre siden. Mange kommersielle profiler er bare IPv4 innvendig: serveren gir deg en v4-adresse og slipper alt annet. Installer en standardrute fra AllowedIPs oppå det, og kjernen sender gjerne IPv6 inn i et grensesnitt som motparten aldri ser.

Test fra klienten mens tunnelen er oppe. ping -6 -c 3 2001:4860:4860::8888 og ip -6 route get 2001:4860:4860::8888 svarer på forskjellige spørsmål: om det kommer en respons tilbake, og hvilken enhet kjernen valgte. Når den andre nevner tunnelen din og den første ikke returnerer noe, er problemet utgangen, ikke ruten.

Hvis du driver utgangen selv, kan klienttesten bestå og veien likevel ende i en blindvei. Bekreft net.ipv6.conf.all.forwarding=1 på gatewayen og at brannmuren godtar pakker som videresendes ut av tunnelen. En korrekt rutet pakke inn i en utgang som nekter å videresende, ser fra klientsiden nøyaktig ut som en rutingsfeil.

Kan klienten beholde veien sin til endepunktet?

Dette er tilfellet som fanget meg på en laptop med et IPv6-kun WireGuard-endepunkt. Endepunktets adresse er en vanlig global adresse, så den faller innenfor ::/0. Rut hele prefikset inn i grensesnittet, og håndtrykkpakkene jager seg selv inn i tunnelen de fortsatt prøver å bygge. Tunnelen kommer aldri opp, og ingenting i klientens utdata sier hvorfor.

wg-quick håndterer dette på Linux. Den utleder ruter fra AllowedIPs, installerer dem i sin egen tabell og legger til en policyregel slik at trafikk til endepunktet først løses via hovedtabellen: regelen suppress_prefixlength 0 som du finner i ip -6 rule. Derfor lykkes wg-quick up der en håndskrevet ip -6 route add default dev wg0 skjærer deg av.

Kontroller begge tilstandene med ip -6 route get <endpoint-v6>, før og etter at tunnelen reises. Hvis svaret endres til tunellenheten din, har du fjernet veien tunnelen trenger. Når du skriver rutene selv, legg til en vertsrute til endepunktet gjennom den opprinnelige gatewayen, eller koble til endepunktet over IPv4 og la IPv6 være til nyttelasten.

Hva må holde seg utenfor tunnelen?

Mer spesifikke ruter slår standardruten, så et on-link-prefiks eller et ULA-område med sin egen rute fortsetter å virke uten ekstra innsats. Dette er den stille grunnen til at så mange IPv4-oppsett med full tunnel overlever: LAN-prefiksene er mer spesifikke enn standardruten og kommer aldri inn i tunnelen.

Det bryter sammen når en lokal enhet er nåbar via en global adresse, noe som er normalt for en printer som samme ruter har gitt et offentlig prefiks, en NAS eller en TV. Disse adressene passer til ::/0 og ingenting annet, så de flytter inn i tunnelen sammen med alt annet og forsvinner.

Bestem per destinasjon, ikke per protokoll. Hvis to eller tre lokale verter betyr noe, gi prefiksene deres en rute ut gjennom det fysiske grensesnittet, eller fjern dem fra det forhandlede settet. Hvis listen fortsetter å vokse, er det ærlige svaret split tunneling for IPv6 med en skriftlig unntaksliste, ikke en standardrute du stadig lapper.

Hvis svaret er nei, blokker det

Å la IPv6 være urutet er ikke det samme som å la det være i fred. En vert med en fungerende IPv6-standardrute fortsetter å bruke den mens tunnelen bærer IPv4, så trafikken forlater ved siden av VPN, og hver tjeneste som foretrekker IPv6, ser din virkelige adresse. Det er en lekkasje, ikke en delt tunnel.

Velg én, og skriv ned hvilken du valgte. Rut standardruten og godta avveiningene ovenfor, eller deaktiver IPv6 så lenge tunnelen varer. Å utelate prefikset fra AllowedIPs er ikke nok i seg selv, fordi operativsystemet beholder sin egen standardrute. På Linux er den grove versjonen sysctl -w net.ipv6.conf.all.disable_ipv6=1; den finere versjonen slipper IPv6 utenfor tunnelen med en brannmurregel. Telefonklienter har en eksplisitt blokker-IPv6-bryter som gjør samme jobb.

Verifiser det som en lekkasje

Reis tunnelen og les tilstanden i stedet for å stole på bryteren. ip -6 route show default skal vise én standardrute, og ip -6 route get for en destinasjon utenfor LAN-et ditt skal navngi tunellenheten. Gjenta begge etter en frakobling: en standardrute som overlever tunnelen, er feilen du lette etter.

Test deretter den andre retningen. Fra en vert på det lokale nettverket, nå klienten på dens lokale IPv6-adresse. Hvis det slutter å virke, var betingelse tre aldri oppfylt, uansett hva rutetabellen hevdet den gangen.

Skriv resultatet der neste person vil finne det: hvilke prefikser som blir lokale, hvorfor, og hva klienten gjør etter en frakobling. To linjer i en runbook sparer den neste ingeniøren for å gjenoppdage endepunktsløkken ved midnatt.