Ska IPv6-trafik gå genom VPN eller direkt?

Två personer bad mig förra månaden om motsatta resultat: en ville att IPv6 skulle täckas av VPN, den andra ville att kontorsskrivaren skulle fortsätta fungera. En enda rutt ::/0 kan inte leverera båda på egen hand. Om den rutten hör hemma inne i tunneln beror på tre villkor, och det första utesluter den för de flesta kommersiella utgångar. Om utgången inte bär IPv6 döljer routningen av standardrutten dit din trafik i en tunnel som inte har någonstans att skicka den.

Tre villkor avgör svaret

Standardrutten är en rad, ::/0, och den matchar varje IPv6-destination utan en mer specifik rutt (RFC 4291). Att installera den är enkelt. Att avgöra om du borde kokar ner till tre villkor.

Villkor ett: utgången du ansluter till har fungerande IPv6 och är villig att vidarebefordra det. Villkor två: din klient kan behålla en väg till tunnelns slutpunkt, som vanligtvis ligger inom det intervall du ska routa. Villkor tre: du kan namnge de lokala IPv6-destinationer som måste stanna utanför tunneln.

Varje villkor misslyckas på sitt eget sätt, och därför kostar gissningar en hel kväll. Ett misslyckat villkor ett ger dig tystnad och en routingtabell som ser korrekt ut. Ett misslyckat villkor två dödar handskakningen några sekunder efter att den börjat. Ett misslyckat villkor tre lämnar en fungerande tunnel och en missnöjd kollega vid skrivaren.

Bär utgången verkligen IPv6?

Ett tunnelgränssnitt med en IPv6-adress bevisar ingenting om andra sidan. Många kommersiella profiler är bara IPv4 inuti: servern ger dig en v4-adress och släpper allt annat. Installera en standardrutt från AllowedIPs ovanpå det, och kärnan skickar gärna IPv6 in i ett gränssnitt vars motpart aldrig ser det.

Testa från klienten medan tunneln är uppe. ping -6 -c 3 2001:4860:4860::8888 och ip -6 route get 2001:4860:4860::8888 svarar på olika frågor: om ett svar kommer tillbaka, och vilken enhet kärnan valde. När den andra namnger din tunnel och den första inte returnerar något, är problemet utgången, inte rutten.

Om du driver utgången själv kan klienttestet passera och vägen ändå sluta i en återvändsgränd. Bekräfta net.ipv6.conf.all.forwarding=1 på gatewayen och att dess brandvägg accepterar paket som vidarebefordras ut ur tunneln. Ett korrekt routat paket in i en utgång som vägrar vidarebefordra ser från klientsidan exakt ut som ett routingfel.

Kan klienten behålla sin väg till slutpunkten?

Det här är fallet som fångade mig på en laptop med en IPv6-endast WireGuard-slutpunkt. Slutpunktens adress är en vanlig global adress, så den faller inom ::/0. Routa hela prefixet in i gränssnittet och handskakningspaketen jagar sig själva in i tunneln de fortfarande försöker bygga. Tunneln kommer aldrig upp, och ingenting i klientens utdata säger varför.

wg-quick hanterar detta på Linux. Den härleder rutter från AllowedIPs, installerar dem i sin egen tabell och lägger till en policyregel så att trafik till slutpunkten först löses via huvudtabellen: regeln suppress_prefixlength 0 som du hittar i ip -6 rule. Därför lyckas wg-quick up där en handskriven ip -6 route add default dev wg0 skär av dig.

Kontrollera båda tillstånden med ip -6 route get <endpoint-v6>, före och efter att tunneln rests. Om svaret ändras till din tunnelenhet har du tagit bort vägen som tunneln behöver. När du skriver rutterna själv, lägg till en värdrutt till slutpunkten via den ursprungliga gatewayen, eller anslut till slutpunkten över IPv4 och låt IPv6 vara till nyttolasten.

Vad måste stanna utanför tunneln?

Mer specifika rutter slår standardrutten, så ett on-link-prefix eller ett ULA-område med egen rutt fortsätter att fungera utan extra ansträngning. Det är den tysta anledningen till att så många IPv4-uppsättningar med full tunnel överlever: LAN-prefixen är mer specifika än standardrutten och kommer aldrig in i tunneln.

Det bryter när en lokal enhet är nåbar via en global adress, vilket är normalt för en skrivare som samma router gav ett offentligt prefix, en NAS eller en tv. Dessa adresser matchar ::/0 och ingenting annat, så de flyttar in i tunneln med allt annat och försvinner.

Bestäm per destination, inte per protokoll. Om två eller tre lokala värdar spelar roll, ge deras prefix en rutt ut genom det fysiska gränssnittet, eller ta bort dem från den förhandlade uppsättningen. Om listan fortsätter växa är det ärliga svaret split tunneling för IPv6 med en skriftlig undantagslista, inte en standardrutt du ständigt lappar.

Om svaret är nej, blockera det

Att lämna IPv6 oroutat är inte samma sak som att lämna det i fred. En värd med en fungerande IPv6-standardrutt fortsätter använda den medan tunneln bär IPv4, så trafiken lämnar bredvid VPN och varje tjänst som föredrar IPv6 ser din riktiga adress. Det är en läcka, inte en delad tunnel.

Välj en och skriv ner vilken du valde. Routa standardrutten och acceptera avvägningarna ovan, eller inaktivera IPv6 så länge tunneln varar. Att utelämna prefixet från AllowedIPs räcker inte i sig, eftersom operativsystemet behåller sin egen standardrutt. På Linux är den grova versionen sysctl -w net.ipv6.conf.all.disable_ipv6=1; den finare versionen släpper IPv6 utanför tunneln med en brandväggsregel. Telefonklienter har en explicit blockeringsbrytare för IPv6 som gör samma jobb.

Verifiera det som en läcka

Res tunneln och läs tillståndet i stället för att lita på brytaren. ip -6 route show default bör visa en enda standardrutt, och ip -6 route get för en destination utanför ditt LAN bör namnge tunnelenheten. Upprepa båda efter en frånkoppling: en standardrutt som överlever tunneln är felet du letade efter.

Testa sedan den andra riktningen. Från en värd på det lokala nätverket, nå klienten på dess lokala IPv6-adress. Om det slutar fungera var villkor tre aldrig uppfyllt, vad routingtabellen än hävdade då.

Skriv resultatet där nästa person hittar det: vilka prefix som blir lokala, varför, och vad klienten gör efter en frånkoppling. Två rader i en runbook sparar nästa ingenjör från att återupptäcka slutpunktsloopen vid midnatt.