IPv6-Verkehr am VPN vorbei: die undichte Route finden

Zwei Testseiten widersprechen sich: die eine meldet die Adresse des Anbieters durch den Tunnel, die zweite meldet dein Heimpräfix, und die naheliegende Schlussfolgerung ist, dass das VPN leckt. Diese Schlussfolgerung überspringt einen Schritt, denn die beiden Berichte haben zwei verschiedene Routing-Entscheidungen ausgelöst, und nur eine davon sollte in den Tunnel gelangen. Die Lücke ist meist real, und sie ist ein Abdeckungsproblem und kein defekter Tunnel. Drei Fragen klären es: welcher Fluss tatsächlich hinausging, welche Route der Kernel dafür wählte und welches Verhalten der Client beabsichtigte.

Arbeite in dieser Reihenfolge. Beantwortet man sie in falscher Reihenfolge, entsteht eine lange Debatte darüber, ob der Client fehlerhaft ist, während die richtige Antwort lautet, dass nie eine IPv6-Route installiert wurde.

Welcher Fluss tatsächlich hinausging und über welchen Adapter

Beginne mit einem Test, der die verwendete Familie benennt, und notiere dann die Anwendung, das Zugangsnetz, das aktive Profil und ob die Verbindung überhaupt IPv6 anbietet. Diese vier Fakten machen zwei Läufe vergleichbar, und den vierten vergessen die Leute: ein Netz ohne v6-Präfix kann kein v6 lecken, und ein Netz, das später eines hinzufügt, ändert die Antwort.

Sende eine Anfrage pro Familie, statt eine Seite zu laden und ihr Ergebnis abzulesen. Eine einzelne Seite kann v6- und v4-Ressourcen mischen, ein Hintergrundprozess kann sich anders verhalten als der Tab vor dir, und eine zwischengespeicherte Antwort kann den Netzwerkwechsel überleben, den du testen willst. Lege das getestete Ziel fest und notiere es, damit ein Wiederholungslauf dasselbe misst.

Die Route lesen, die der Kernel gewählt hat

Die Routentabelle beantwortet die Frage, die der Browser nicht beantworten kann. Frage das System, wohin ein bestimmtes Ziel geht, und beziehe Policy-Regeln ebenso ein wie die sichtbare Standardroute, denn beide können sie überschreiben:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Ein spezifischeres Präfix ist der übliche Grund, warum ein Ziel außerhalb des Tunnels liegt, während alles andere drinnen bleibt, und eine Policy-Regel kann dasselbe mit höherer Priorität als jede Route bewirken. Lies auch die Metrik, denn zwei Einträge für dasselbe Präfix entscheiden sich nach Metrik und nicht nach ihrer Reihenfolge auf dem Bildschirm. Unter Windows ist die entsprechende Auflistung Get-NetRoute -AddressFamily IPv6, nach Metrik sortiert, damit sie der Entscheidungsreihenfolge entspricht. Eine Regel, die in der Tabelle korrekt aussieht, kann trotzdem gegen eine Policy-Regel mit niedrigerer Nummer verlieren, weshalb die Regelliste im selben Atemzug wie die Routenliste gehört.

Woher die IPv6-Politik des Clients kommt

Ein Client kann dafür gebaut sein, v6 durch den Tunnel zu führen, es abzulehnen oder eine benannte Ausnahme zuzulassen, und diese drei Absichten ergeben drei verschiedene korrekte Ergebnisse. Lies das Profil und die Dokumentation des Clients, bevor du eine Beobachtung ein Leck nennst, denn ein Client, der v6 blockiert, während das Betriebssystem weiterhin Neighbor Discovery auf dem physischen Link sendet, verhält sich wie vorgesehen.

Eine Anwendung, die bewusst vom Tunnel ausgeschlossen ist, ist ein anderer Fall als eine Familie, die der Tunnel nie getragen hat. Das erste ist eine Entscheidung über ein Programm, das zweite eine Lücke in der Abdeckung, und die Reparatur unterscheidet sich entsprechend. Lies die Liste der ausgeschlossenen Programme im Client, bevor du nach einer Route suchst, die nie existieren sollte.

Gezielte Beobachtung, wenn die Tabelle widerspricht

Wenn die Routensuche mehrdeutig ist, kann eine Schnittstellenbeobachtung auf dem Host sie klären, aber nur, wenn sie auf die Frage zielt. Verkehr zum VPN-Endpunkt selbst wird planmäßig über den physischen Adapter laufen; entscheidend ist, ob der Anwendungsfluss, der ganz woanders adressiert ist, dort ebenfalls auftaucht. Filtere die Aufzeichnung auf das getestete Ziel, statt alles zu sammeln.

Eine breite Aufzeichnung legt weit mehr persönlichen Verkehr offen, als die eine Frage erfordert. Sie beantwortet die Frage auch weniger klar, weil der Fluss, der dich interessiert, in einem Strom unzusammenhängender Verbindungen begraben ankommt. Filtere auf das getestete Ziel, stoppe nach einer Handvoll Pakete und lösche die Aufzeichnung.

Drei Wege, die Lücke zu schließen

Führe die Familie durch den Tunnel, blockiere sie im Client, wenn der Tunnel sie nicht tragen kann, oder erfasse eine bewusste Ausnahme mit einem Verantwortlichen und einem Prüfdatum. Jede davon ist vertretbar, und das Einzige, was nicht vertretbar ist, ist die Wahl implizit zu lassen, denn eine implizite Wahl ist genau das, was das Leck ausmacht. Hat der Tunnel gar keinen v6-Ausgang, ist es sowohl ehrlich als auch testbar, v6 im Client abzulehnen. Entscheidend ist, dass die Wahl dort notiert ist, wo die nächste Person sie findet, und nicht sechs Monate später aus dem Verhalten abgeleitet wird.

Wiederhole die Prüfung nach einem erneuten Verbindungsaufbau und nach einem Wechsel zwischen Netzen, denn eine für den vorherigen Link installierte Route kann den Wechsel überleben. Halte dann das Ziel, die gewählte Route, die Client-Politik und die im Test verwendete Familie fest, damit die nächste Person eine Entscheidung liest, statt sie neu herzuleiten. RFC 7359 dokumentiert Dual-Stack-Lecks als Designproblem und nicht als Fehler, und es ist die Referenz, die man zitiert, wenn jemand behauptet, ein funktionierender v4-Tunnel decke alles ab.