Soll IPv6-Datenverkehr über das VPN oder direkt laufen?

Zwei Leute baten mich letzten Monat um entgegengesetzte Ergebnisse: Der eine wollte IPv6 durch das VPN abgedeckt, der andere wollte, dass der Bürodrucker weiter funktioniert. Eine einzige Route ::/0 kann beides nicht allein liefern. Ob diese Route in den Tunnel gehört, hängt von drei Bedingungen ab, und die erste schließt sie für die meisten kommerziellen Ausgänge aus. Trägt der Ausgang kein IPv6, versteckt das Leiten der Standardroute dorthinein Ihren Verkehr in einem Tunnel, der ihn nirgendwohin senden kann.

Drei Bedingungen entscheiden die Antwort

Die Standardroute ist eine Zeile, ::/0, und sie passt auf jedes IPv6-Ziel ohne spezifischere Route (RFC 4291). Sie zu installieren ist einfach. Die Entscheidung, ob Sie es tun sollten, läuft auf drei Bedingungen hinaus.

Bedingung eins: Der Ausgang, mit dem Sie sich verbinden, hat funktionierendes IPv6 und ist bereit, es weiterzuleiten. Bedingung zwei: Ihr Client kann einen Pfad zum Tunnelendpunkt halten, der meist innerhalb des Bereichs liegt, den Sie routen wollen. Bedingung drei: Sie können die lokalen IPv6-Ziele benennen, die außerhalb des Tunnels bleiben müssen.

Jede Bedingung scheitert auf ihre eigene Weise, deshalb kostet Raten einen ganzen Abend. Eine gescheiterte Bedingung eins beschert Ihnen Stille und eine Routentabelle, die richtig aussieht. Eine gescheiterte Bedingung zwei tötet den Handshake wenige Sekunden nach dem Start. Eine gescheiterte Bedingung drei hinterlässt einen funktionierenden Tunnel und einen unzufriedenen Kollegen am Drucker.

Trägt der Ausgang tatsächlich IPv6?

Eine Tunnelschnittstelle mit einer IPv6-Adresse beweist nichts über die Gegenseite. Viele kommerzielle Profile sind innen nur IPv4: Der Server gibt Ihnen eine v4-Adresse und verwirft alles andere. Installieren Sie darüber eine Standardroute aus AllowedIPs, und der Kernel schickt IPv6 fröhlich in eine Schnittstelle, deren Gegenstelle es nie sieht.

Testen Sie vom Client aus, während der Tunnel steht. ping -6 -c 3 2001:4860:4860::8888 und ip -6 route get 2001:4860:4860::8888 beantworten verschiedene Fragen: ob eine Antwort zurückkommt und welches Gerät der Kernel gewählt hat. Wenn das zweite Ihren Tunnel nennt und das erste nichts zurückgibt, ist der Ausgang das Problem, nicht die Route.

Betreiben Sie den Ausgang selbst, kann der Clienttest bestehen und der Pfad trotzdem im Nichts enden. Bestätigen Sie net.ipv6.conf.all.forwarding=1 auf dem Gateway und dass dessen Firewall Pakete annimmt, die aus dem Tunnel weitergeleitet werden. Ein korrekt geroutetes Paket in einen Ausgang, der die Weitergabe verweigert, sieht von der Clientseite exakt wie ein Routingfehler aus.

Kann der Client seinen Pfad zum Endpunkt behalten?

Das ist der Fall, der mich auf einem Laptop mit einem reinen IPv6-WireGuard-Endpunkt erwischt hat. Die Endpunktadresse ist eine gewöhnliche globale Adresse, also fällt sie in ::/0. Routen Sie das ganze Präfix in die Schnittstelle, und die Handshake-Pakete jagen sich selbst in den Tunnel, den sie noch aufzubauen versuchen. Der Tunnel kommt nie hoch, und nichts in der Client-Ausgabe sagt, warum.

wg-quick behandelt das unter Linux. Es leitet Routen aus AllowedIPs ab, installiert sie in einer eigenen Tabelle und fügt eine Richtlinienregel hinzu, damit Verkehr zum Endpunkt zuerst über die Haupttabelle aufgelöst wird: die Regel suppress_prefixlength 0, die Sie in ip -6 rule finden. Deshalb gelingt wg-quick up dort, wo ein handgeschriebenes ip -6 route add default dev wg0 Sie abschneidet.

Prüfen Sie beide Zustände mit ip -6 route get <endpoint-v6>, vor und nach dem Hochfahren des Tunnels. Ändert sich die Antwort auf Ihr Tunnelgerät, haben Sie den Pfad entfernt, den der Tunnel braucht. Wenn Sie die Routen selbst schreiben, fügen Sie eine Hostroute zum Endpunkt über das ursprüngliche Gateway hinzu, oder verbinden Sie sich über IPv4 zum Endpunkt und überlassen Sie IPv6 der Nutzlast.

Was muss außerhalb des Tunnels bleiben?

Spezifischere Routen schlagen die Standardroute, deshalb funktioniert ein On-Link-Präfix oder ein ULA-Bereich mit eigener Route ohne zusätzlichen Aufwand weiter. Das ist der stille Grund, warum so viele IPv4-Aufbauten mit vollem Tunnel überleben: Die LAN-Präfixe sind spezifischer als die Standardroute und geraten nie in den Tunnel.

Es bricht, wenn ein lokales Gerät über eine globale Adresse erreichbar ist, was für einen Drucker normal ist, dem derselbe Router ein öffentliches Präfix gegeben hat, für ein NAS oder einen Fernseher. Diese Adressen passen auf ::/0 und nichts sonst, also wandern sie mit allem anderen in den Tunnel und verschwinden.

Entscheiden Sie pro Ziel, nicht pro Protokoll. Wenn zwei oder drei lokale Hosts wichtig sind, geben Sie ihren Präfixen eine Route über die physische Schnittstelle, oder nehmen Sie sie aus dem ausgehandelten Satz. Wächst die Liste weiter, ist die ehrliche Antwort Split-Tunneling für IPv6 mit einer schriftlichen Ausnahmeliste, nicht eine Standardroute, die Sie ständig flicken.

Wenn die Antwort nein ist, blockieren Sie es

IPv6 ungeroutet zu lassen ist nicht dasselbe, wie es in Ruhe zu lassen. Ein Host mit funktionierender IPv6-Standardroute nutzt sie weiter, während der Tunnel IPv4 trägt, also verlässt der Verkehr neben dem VPN, und jeder Dienst, der IPv6 bevorzugt, sieht Ihre echte Adresse. Das ist ein Leck, kein Split-Tunnel.

Wählen Sie eines und schreiben Sie auf, welches Sie gewählt haben. Routen Sie die Standardroute und akzeptieren Sie die Kompromisse oben, oder deaktivieren Sie IPv6 für die Dauer des Tunnels. Das Präfix aus AllowedIPs wegzulassen reicht allein nicht, weil das Betriebssystem seine eigene Standardroute behält. Unter Linux ist die grobe Variante sysctl -w net.ipv6.conf.all.disable_ipv6=1; die feinere lässt IPv6 mit einer Firewallregel außerhalb des Tunnels fallen. Telefon-Clients haben einen ausdrücklichen IPv6-Blockieren-Schalter, der dasselbe tut.

Prüfen Sie es wie ein Leck

Fahren Sie den Tunnel hoch und lesen Sie den Zustand, statt dem Schalter zu vertrauen. ip -6 route show default sollte eine Standardroute zeigen, und ip -6 route get sollte für ein Ziel außerhalb Ihres LANs das Tunnelgerät nennen. Wiederholen Sie beides nach einem Trennen: Eine Standardroute, die den Tunnel überlebt, ist der Fehler, den Sie gesucht haben.

Testen Sie dann die andere Richtung. Erreichen Sie von einem Host im lokalen Netz den Client unter seiner lokalen IPv6-Adresse. Hört das auf zu funktionieren, war Bedingung drei nie erfüllt, was die Routentabelle damals auch behauptet hat.

Schreiben Sie das Ergebnis dorthin, wo die nächste Person es findet: welche Präfixe lokal bleiben, warum, und was der Client nach einem Trennen tut. Zwei Zeilen in einem Runbook ersparen dem nächsten Ingenieur, die Endpunktschleife um Mitternacht neu zu entdecken.