Moet IPv6-verkeer via de VPN of direct?

Twee mensen vroegen me vorige maand om tegengestelde resultaten: de een wilde dat IPv6 door de VPN werd gedekt, de ander wilde dat de kantoorprinter bleef werken. Eén route ::/0 kan beide niet alleen leveren. Of die route binnen de tunnel hoort, hangt af van drie voorwaarden, en de eerste sluit hem uit voor de meeste commerciële uitgangen. Als de uitgang geen IPv6 draagt, verbergt het routeren van de standaardroute daarnaar uw verkeer in een tunnel die nergens heeft om het heen te sturen.

Drie voorwaarden bepalen het antwoord

De standaardroute is één regel, ::/0, en hij past bij elke IPv6-bestemming zonder specifiekere route (RFC 4291). Hem installeren is eenvoudig. Beslissen of u het zou moeten doen, komt neer op drie voorwaarden.

Voorwaarde één: de uitgang waarmee u verbindt, heeft werkende IPv6 en is bereid het door te geven. Voorwaarde twee: uw client kan een pad naar het tunneleindpunt houden, dat meestal binnen het bereik ligt dat u gaat routeren. Voorwaarde drie: u kunt de lokale IPv6-bestemmingen benoemen die buiten de tunnel moeten blijven.

Elke voorwaarde faalt op zijn eigen manier, daarom kost gissen een hele avond. Een mislukte voorwaarde één geeft u stilte en een routetabel die er correct uitziet. Een mislukte voorwaarde twee doodt de handshake enkele seconden na de start. Een mislukte voorwaarde drie laat een werkende tunnel en een ontevreden collega bij de printer achter.

Draagt de uitgang werkelijk IPv6?

Een tunnelinterface met een IPv6-adres bewijst niets over de andere kant. Veel commerciële profielen zijn van binnen alleen IPv4: de server geeft u een v4-adres en gooit al het andere weg. Installeer daar bovenop een standaardroute uit AllowedIPs en de kernel stuurt IPv6 graag naar een interface waarvan de tegenpartij het nooit ziet.

Test vanaf de client terwijl de tunnel actief is. ping -6 -c 3 2001:4860:4860::8888 en ip -6 route get 2001:4860:4860::8888 beantwoorden verschillende vragen: of er een antwoord terugkomt, en welk apparaat de kernel koos. Wanneer de tweede uw tunnel noemt en de eerste niets teruggeeft, is de uitgang het probleem, niet de route.

Als u de uitgang zelf beheert, kan de clienttest slagen en de weg alsnog doodlopen. Bevestig net.ipv6.conf.all.forwarding=1 op de gateway en dat de firewall pakketten accepteert die uit de tunnel worden doorgestuurd. Een correct gerouteerd pakket naar een uitgang die doorgeven weigert, ziet er vanaf de clientzijde precies uit als een routingfout.

Kan de client zijn pad naar het eindpunt behouden?

Dit is het geval dat mij pakte op een laptop met een alleen-IPv6 WireGuard-eindpunt. Het adres van het eindpunt is een gewoon globaal adres, dus het valt binnen ::/0. Routeer het hele prefix de interface in en de handshakepakketten jagen zichzelf de tunnel in die ze nog proberen te bouwen. De tunnel komt nooit omhoog, en niets in de uitvoer van de client zegt waarom.

wg-quick regelt dit op Linux. Het leidt routes af uit AllowedIPs, installeert ze in een eigen tabel en voegt een beleidsregel toe zodat verkeer naar het eindpunt eerst via de hoofdtabel wordt opgelost: de regel suppress_prefixlength 0 die u in ip -6 rule vindt. Daarom slaagt wg-quick up waar een handgeschreven ip -6 route add default dev wg0 u afsnijdt.

Controleer beide toestanden met ip -6 route get <endpoint-v6>, voor en na het opzetten van de tunnel. Als het antwoord naar uw tunnelapparaat verandert, hebt u het pad verwijderd dat de tunnel nodig heeft. Wanneer u de routes zelf schrijft, voeg dan een hostroute naar het eindpunt via de oorspronkelijke gateway toe, of verbind met het eindpunt via IPv4 en laat IPv6 aan de payload.

Wat moet buiten de tunnel blijven?

Specifiekere routes verslaan de standaardroute, dus een on-link prefix of een ULA-bereik met een eigen route blijft zonder extra moeite werken. Dit is de stille reden waarom zoveel IPv4-opstellingen met volledige tunnel overleven: de LAN-prefixen zijn specifieker dan de standaardroute en komen nooit in de tunnel.

Het breekt wanneer een lokaal apparaat bereikbaar is via een globaal adres, wat normaal is voor een printer die dezelfde router een openbaar prefix gaf, een NAS of een televisie. Die adressen passen bij ::/0 en niets anders, dus ze verhuizen mee de tunnel in en verdwijnen.

Beslis per bestemming, niet per protocol. Als twee of drie lokale hosts ertoe doen, geef hun prefixen een route naar buiten via de fysieke interface, of haal ze uit de onderhandelde set. Als de lijst blijft groeien, is het eerlijke antwoord split tunneling voor IPv6 met een geschreven uitzonderingenlijst, niet een standaardroute die u blijft patchen.

Als het antwoord nee is, blokkeer het

IPv6 ongerouteerd laten is niet hetzelfde als het met rust laten. Een host met een werkende IPv6-standaardroute blijft die gebruiken terwijl de tunnel IPv4 draagt, dus het verkeer verlaat naast de VPN en elke dienst die IPv6 verkiest, ziet uw echte adres. Dat is een lek, geen split tunnel.

Kies er één en schrijf op welke u koos. Routeer de standaardroute en accepteer de afwegingen hierboven, of schakel IPv6 uit zolang de tunnel duurt. Het prefix uit AllowedIPs weglaten is op zichzelf niet genoeg, omdat het besturingssysteem zijn eigen standaardroute houdt. Op Linux is de botte versie sysctl -w net.ipv6.conf.all.disable_ipv6=1; de fijnere versie laat IPv6 buiten de tunnel vallen met een firewallregel. Telefoonclients hebben een expliciete schakelaar om IPv6 te blokkeren die hetzelfde doet.

Verifieer het als een lek

Zet de tunnel op en lees de toestand in plaats van de schakelaar te vertrouwen. ip -6 route show default zou één standaardroute moeten tonen, en ip -6 route get zou voor een bestemming buiten uw LAN het tunnelapparaat moeten noemen. Herhaal beide na een verbreking: een standaardroute die de tunnel overleeft, is de fout die u zocht.

Test daarna de andere richting. Bereik vanaf een host op het lokale netwerk de client op zijn lokale IPv6-adres. Als dat stopt met werken, was voorwaarde drie nooit vervuld, wat de routetabel toen ook beweerde.

Schrijf de uitkomst waar de volgende persoon die vindt: welke prefixen lokaal blijven, waarom, en wat de client na een verbreking doet. Twee regels in een runbook besparen de volgende engineer het herontdekken van de eindpuntslus om middernacht.