IPv6-Leck trotz VPN: Dein System bevorzugt IPv6, und genau deshalb leckt es

Dein VPN ist verbunden. Der Tunnel steht, der Client meldet geschützt, und dein IPv4-Verkehr läuft tatsächlich hindurch. Und eine Website, die du besuchst, protokolliert trotzdem deine echte Adresse, weil sie dich über IPv6 erreicht hat.

Hier ist kein Fehler zu finden. Das sind zwei korrekte Systeme, die sich uneinig sind, und diese Uneinigkeit steht in einem Standard.

Dein System verhält sich nicht falsch, es befolgt RFC 6724

Wenn ein Ziel sowohl über IPv4 als auch über IPv6 erreichbar ist, muss etwas entscheiden. Dieses Etwas ist RFC 6724, die eine Standard-Policy-Tabelle für die Adressauswahl definiert. Drei ihrer Zeilen zählen hier:

Prefix        Precedence Label
::1/128               50     0
::/0                  40     1
::ffff:0:0/96         35     4

::/0 steht für IPv6 allgemein. ::ffff:0:0/96 ist die Art, wie IPv4-Adressen in dieser Tabelle dargestellt werden. Vierzig schlägt fünfunddreißig, und die Regel zur Zielauswahl ist eindeutig: bei Precedence(DA) > Precedence(DB) ist DA zu bevorzugen.

Die RFC nennt die Folge im Klartext, statt sie dich erschließen zu lassen: ein weiterer Effekt der Standard-Policy-Tabelle ist, die Kommunikation über IPv6-Adressen der über IPv4-Adressen vorzuziehen, sofern passende Quelladressen verfügbar sind.

Für jede Dual-Stack-Seite, die du besuchst, greift dein Betriebssystem also zuerst zu IPv6. Das ist korrektes Verhalten, und es ist weit älter als dein VPN.

Warum daraus ein Leck wird

Setze nun ein VPN darüber, das nur IPv4 transportiert.

Deine Maschine behält eine native IPv6-Adresse von deinem Provider. Der Tunnel beansprucht den IPv6-Verkehr nicht, also fängt ihn nichts ab. Dein System bevorzugt nach obiger Regel IPv6 für jedes Ziel, das es anbietet. Das Ergebnis: Dein bevorzugter Weg ist derjenige, der am Tunnel vorbeiführt, und der geschützte Weg bekommt nur das, was IPv6 nicht bedienen konnte.

Deshalb übersieht man dieses Leck so leicht. Es sieht nicht nach einer Störung aus. Dein VPN meldet verbunden, weil es das ist. Deine IPv4-Prüfungen bestehen, weil sie wirklich bestehen. Der entweichende Verkehr ist genau der, den dein System für den besten hielt.

Prüfen, und der Fehler, der die Prüfung wertlos macht

Die Prüfung ist einfach: mit verbundenem VPN nachsehen, was eine Website tatsächlich sieht, und dabei gezielt die IPv6-Zeile lesen, statt kurz auf die IPv4-Zeile zu schauen und weiterzugehen.

Gehört die angezeigte IPv6-Adresse zu deinem Anschluss statt zum VPN-Anbieter, liegt IPv6 außerhalb des Tunnels. Erscheint gar keine IPv6-Adresse, hat dein Netz entweder keine oder sie wird blockiert, und beides ist aus Leck-Sicht unbedenklich.

Zwei Dinge ruinieren diese Prüfung in der Praxis:

Vor dem Verbinden testen. Die Frage ist nicht, wie du ungeschützt aussiehst. Sie lautet, was entweicht, während du dich geschützt glaubst.

Nur einmal testen. Eine Konfiguration, die heute IPv6 führt, kann nach einer erneuten Verbindung, einem Netzwerkwechsel oder dem Umschalten von WLAN auf Mobilfunk damit aufhören, weil sich die verfügbaren Adressen mit dem Netz ändern. Ein einzelnes sauberes Ergebnis beweist, dass die Einrichtung in einem Netz zu einem Zeitpunkt korrekt war.

Die eine Zeile, bei WireGuard

WireGuard macht die Ursache ungewöhnlich gut lesbar, weil dieselbe Einstellung sowohl bestimmt, was hereinkommt, als auch, wohin Dinge hinausgehen. Das wg-Handbuch definiert AllowedIPs als eine kommagetrennte Liste von IP-Adressen (v4 oder v6) mit CIDR-Masken, von denen eingehender Verkehr für diesen Peer erlaubt ist und zu denen ausgehender Verkehr für diesen Peer geleitet wird, und ergänzt, dass der Sammelausdruck 0.0.0.0/0 für alle IPv4-Adressen und ::/0 für alle IPv6-Adressen angegeben werden kann.

Lies das als Routing-Anweisung, denn genau das ist es. Ein Peer, der nur 0.0.0.0/0 führt, leitet IPv4 in den Tunnel und sagt nichts über IPv6, das damit weiter den normalen Weg nimmt. Ein zusätzliches ::/0 leitet auch IPv6 hinein.

Eine Bedingung gilt: Der Tunnel braucht dafür eine eigene IPv6-Adresse. Vergibt dein Anbieter keine, erzeugt das Routen von ::/0 in einen Tunnel ohne IPv6-Endpunkt keine IPv6-Konnektivität. Genau dann wird das Blockieren von IPv6 zum ehrlichen Rückfall statt zur Abkürzung.

IPv6 blockieren wirkt, und kostet etwas

IPv6 auf der Maschine zu deaktivieren entfernt den bevorzugten Weg, alles fällt auf IPv4 und damit in den Tunnel zurück. Das ist wirksam, und mehrere VPN-Clients tun genau das unter der Bezeichnung IPv6-Leckschutz.

Der Preis ist allerdings real. Du verlierst IPv6 für alles andere auf dieser Maschine, auch in Netzen, in denen es der einzige nutzbare Transport ist, und die Einstellung überlebt den Anlass, aus dem du sie geändert hast. Ein halbes Jahr später wird ein völlig unabhängiges Verbindungsproblem sehr schwer zu diagnostizieren, weil niemand mehr weiß, dass IPv6 abgeschaltet war.

IPv6 durch den Tunnel zu routen erhält die Fähigkeit und löst dasselbe Problem. Bevorzuge es, wann immer dein Anbieter es unterstützt, und behandle das Blockieren als Rückfall für die Fälle, in denen er es nicht tut.

Der Kill Switch deckt das nicht ab

Getrennt zu sagen, weil beides auf derselben Einstellungsseite verwechselt wird.

Ein Kill Switch wartet darauf, dass der Tunnel ausfällt, und kappt dann den Verkehr. Ein IPv6-Leck geschieht bei stehendem Tunnel. Es gibt keinen Abbruch zu erkennen, kein Ausfallereignis, nichts, worauf der Schalter reagieren könnte. Ein einwandfrei arbeitender Kill Switch wird tadellos seinen Dienst tun, während IPv6-Verkehr an ihm vorbeigeht.

Bietet dein Client IPv6-Leckschutz als eigenen Schalter an, ist das ein anderer Mechanismus, und das eine zu haben verschafft dir nicht das andere.

Kurz gefasst

Ein IPv6-Leck ist kein kaputtes VPN. Es sind RFC 6724, die deinem System sagt, IPv6 zu bevorzugen, ein Tunnel, der nur IPv4 trägt, und die vollkommen logische Folge dieser beiden Tatsachen.

Prüfe mit verbundenem VPN, lies die IPv6-Zeile, und wiederhole es nach einem Netzwerkwechsel. Bei WireGuard entscheidet AllowedIPs, und ::/0 ist es, was IPv6 in den Tunnel leitet. Wo der Tunnel kein eigenes IPv6 hat, ist das Blockieren von IPv6 ein legitimer Rückfall mit einem Preis, den du dir dort notieren solltest, wo du ihn wiederfindest.

Die Standard-Policy-Tabelle, die Precedence-Werte, die Regel zur Zielauswahl und die Aussage, dass die Tabelle IPv6-Kommunikation gegenüber IPv4 bevorzugt, stammen aus RFC 6724. Die Definition von AllowedIPs und die Sammelnotation für 0.0.0.0/0 und ::/0 stammen aus der Handbuchseite wg(8). Beide wurden zum Zeitpunkt der Abfassung geprüft.

Verwandte Leitfäden

• Vollständiges VPN-Sicherheitsaudit - die sieben Prüfungen, die einmal lohnen, und diese ist eine davon.
• Der VPN-Kill-Switch erklärt - der Mechanismus für den umgekehrten Fall, wenn der Tunnel wirklich abbricht.