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

To personar bad meg i førre månad om motsette resultat: den eine ville at IPv6 skulle dekkjast av VPN, den andre ville at kontorprinteren skulle halde fram med å verke. Éi einskild rute ::/0 kan ikkje levere begge åleine. Om den ruta høyrer til inne i tunnelen, kjem an på tre vilkår, og det første utelukkar ho for dei fleste kommersielle utgangane. Viss utgangen ikkje ber IPv6, skjuler rutinga av standardruta dit trafikken din i ein tunnel som ikkje har nokon stad å sende han.

Tre vilkår avgjer svaret

Standardruta er éi line, ::/0, og ho passar til kvar IPv6-destinasjon utan ei meir spesifikk rute (RFC 4291). Det er enkelt å installere ho. Å avgjere om du bør, kokar ned til tre vilkår.

Vilkår éin: utgangen du koplar til, har fungerande IPv6 og er viljug til å videresende det. Vilkår to: klienten din kan halde ein veg til endepunktet til tunnelen, som vanlegvis ligg innanfor området du er i ferd med å rute. Vilkår tre: du kan namngje dei lokale IPv6-destinasjonane som må halde seg utanfor tunnelen.

Kvart vilkår feilar på sin måte, og difor kostar gjetting ein heil kveld. Eit feila vilkår éin gir deg stille og ei rutetabell som ser rett ut. Eit feila vilkår to drep handtrykket nokre sekund etter at det startar. Eit feila vilkår tre lèt etter seg ein fungerande tunnel og ein misnøgd kollega ved printeren.

Ber utgangen faktisk IPv6?

Eit tunellgrensesnitt med ei IPv6-adresse beviser ingenting om den andre sida. Mange kommersielle profilar er berre IPv4 innvendig: serveren gir deg ei v4-adresse og slepp alt anna. Installer ei standardrute frå AllowedIPs oppå det, og kjernen sender gjerne IPv6 inn i eit grensesnitt som motparten aldri ser.

Test frå klienten medan tunnelen er oppe. ping -6 -c 3 2001:4860:4860::8888 og ip -6 route get 2001:4860:4860::8888 svarar på ulike spørsmål: om det kjem eit svar tilbake, og kva eining kjernen valde. Når den andre nemner tunnelen din og den første ikkje returnerer noko, er problemet utgangen, ikkje ruta.

Viss du driv utgangen sjølv, kan klienttesten bestå og vegen likevel enda i ein blindveg. Stadfest net.ipv6.conf.all.forwarding=1 på gatewayen og at brannmuren godtek pakkar som blir videresende ut av tunnelen. Ein korrekt ruta pakke inn i ein utgang som nektar å videresende, ser frå klientsida nøyaktig ut som ein rutefeil.

Kan klienten halde vegen sin til endepunktet?

Dette er tilfellet som fanga meg på ein laptop med eit IPv6-berre WireGuard-endepunkt. Adressa til endepunktet er ei vanleg global adresse, så ho fell innanfor ::/0. Rut heile prefikset inn i grensesnittet, og handtrykkpakka jagar seg sjølve inn i tunnelen dei framleis prøver å byggje. Tunnelen kjem aldri opp, og ingenting i utdataa til klienten seier kvifor.

wg-quick handterer dette på Linux. Han leier ruter ut frå AllowedIPs, installerer dei i sin eigen tabell og legg til ei policyregel slik at trafikk til endepunktet først blir løyst via hovudtabellen: regelen suppress_prefixlength 0 som du finn i ip -6 rule. Difor lykkast wg-quick up der ei handskriven ip -6 route add default dev wg0 skjer deg av.

Kontroller begge tilstandane med ip -6 route get <endpoint-v6>, før og etter at tunnelen blir reist. Viss svaret endrar seg til tunelleininga di, har du fjerna vegen tunnelen treng. Når du skriv rutene sjølv, legg til ei vertsrute til endepunktet gjennom den opphavlege gatewayen, eller kople til endepunktet over IPv4 og lat IPv6 vere til nyttelasta.

Kva må halde seg utanfor tunnelen?

Meir spesifikke ruter slår standardruta, så eit on-link-prefiks eller eit ULA-område med si eiga rute held fram med å verke utan ekstra innsats. Dette er den stille grunnen til at så mange IPv4-oppsett med full tunnel overlever: LAN-prefiksa er meir spesifikke enn standardruta og kjem aldri inn i tunnelen.

Det bryt saman når ei lokal eining er nåbar via ei global adresse, noko som er normalt for ein printer som same ruter har gitt eit offentleg prefiks, ein NAS eller ein TV. Desse adressene passar til ::/0 og ingenting anna, så dei flyttar inn i tunnelen saman med alt anna og forsvinn.

Avgjer per destinasjon, ikkje per protokoll. Viss to eller tre lokale vertar betyr noko, gi prefiksa deira ei rute ut gjennom det fysiske grensesnittet, eller fjern dei frå det forhandla settet. Viss lista held fram med å vekse, er det ærlege svaret split tunneling for IPv6 med ei skriftleg unntaksliste, ikkje ei standardrute du stadig lappar.

Viss svaret er nei, blokker det

Å la IPv6 vere uruta er ikkje det same som å la det vere i fred. Ein vert med ei fungerande IPv6-standardrute held fram med å bruke ho medan tunnelen ber IPv4, så trafikken forlèt ved sida av VPN, og kvar teneste som føretrekk IPv6, ser den verkelege adressa di. Det er ein lekkasje, ikkje ein delt tunnel.

Vel éin, og skriv ned kva du valde. Rut standardruta og godta avvegingane ovanfor, eller deaktiver IPv6 så lenge tunnelen varer. Å utelate prefikset frå AllowedIPs er ikkje nok i seg sjølv, fordi operativsystemet held på si eiga standardrute. På Linux er den grove versjonen sysctl -w net.ipv6.conf.all.disable_ipv6=1; den finare versjonen slepp IPv6 utanfor tunnelen med ei brannmurregel. Telefonklientar har ein eksplisitt blokker-IPv6-brytar som gjer same jobben.

Verifiser det som ein lekkasje

Reis tunnelen og les tilstanden i staden for å stole på brytaren. ip -6 route show default skal vise éi standardrute, og ip -6 route get for ein destinasjon utanfor LAN-et ditt skal namngje tunelleininga. Gjenta begge etter ein fråkopling: ei standardrute som overlever tunnelen, er feilen du leita etter.

Test deretter den andre retninga. Frå ein vert på det lokale nettverket, nå klienten på den lokale IPv6-adressa hans. Viss det sluttar å verke, var vilkår tre aldri oppfylt, uansett kva rutetabellen hevda den gongen.

Skriv resultatet der neste person vil finne det: kva prefiks som blir lokale, kvifor, og kva klienten gjer etter ein fråkopling. To linjer i ein runbook sparer den neste ingeniøren for å gjenoppdage endepunktsløkka ved midnatt.