IPv6 abschalten, um ein VPN-Leck zu beheben? Entscheiden Sie lieber die Richtlinie

Eine Adresse aus dem IPv6-Bereich taucht auf einer Testseite auf, der Tunnel trägt sie offensichtlich nicht, und der beliebteste Ratschlag im Internet lautet, IPv6 überall abzuschalten. Dieser Befehl bringt das Panel tatsächlich zum Schweigen. Er entfernt aber auch ein Protokoll, von dem das Zugangsnetz abhängen kann, und er lässt Sie ohne jede Ahnung zurück, ob die Adresse ein echtes Leck war, eine Link-Local-Schnittstellenadresse oder ein Resolver, der seine Arbeit tut. Drei Bedingungen entscheiden über die richtige Kontrolle, und nur eine davon führt zum Blockieren.

Stellen Sie fest, was das Werkzeug tatsächlich gemessen hat

Der häufigste Fehlalarm ist eine Link-Local-Adresse, die mit fe80: beginnt und auf jeder IPv6-fähigen Schnittstelle existiert, unabhängig davon, ob die Maschine das Internet über IPv6 erreichen kann. Sie erscheint in Schnittstellenlisten und in manchen Anwendungsdiagnosen und sagt nichts über Ihren Verkehrsweg aus.

Der zweite Fehlalarm ist eine eindeutige lokale Adresse in fc00::/7, einem privaten Bereich, der innerhalb eines Netzes verwendet wird. Ein Werkzeug, das jede Adresse des Hosts ausgibt, listet sie gern neben der öffentlichen auf. Wer schnell liest, nennt das ein Leck und verbringt dann eine Stunde mit einem Problem, das es nicht gibt.

Der dritte ist überhaupt kein Fehlalarm. Eine globale Adresse, die außerhalb des Tunnels ins Internet gelangt, ist das echte Leck, und es lohnt sich, sie zu messen, bevor Sie irgendetwas entscheiden:

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

Wenn der erste Befehl eine globale Adresse ausgibt und der dritte eine öffentliche IPv6-Adresse zurückgibt, die nicht die des Tunnels ist, haben Sie einen echten Weg am Tunnel vorbei. Wenn der erste nichts als Link-Local-Einträge ausgibt, gab es nie ein Leck zu beheben.

Drei Bedingungen entscheiden über die Kontrolle

Die Entscheidung lautet nicht "IPv6 gut" oder "IPv6 schlecht". Es geht darum, in welcher von drei Situationen Sie sich befinden, und jede hat eine andere richtige Antwort mit anderen Kosten, wenn Sie danebenliegen.

Die erste Zeile ist das, was die Leute meist meinen, und sie ist berechtigt. Ein Client, dessen Ausgang kein IPv6 unterstützt, sollte den nativen IPv6-Verkehr des Hosts nicht stillschweigend hinauslassen, denn das ist das dokumentierte Dual-Stack-Leck. Der Punkt ist, ihn als erklärte Richtlinie zu blockieren, nicht ein Protokoll im Kernel abzuschalten. Das sichtbare Ergebnis ist identisch, und nur eines von beidem lässt sich später prüfen.

Die dritte Zeile ist der Punkt, an dem der pauschale Ratschlag aktiv schädlich wird. Mobilfunknetzbetreiber und manche Heimanschlüsse betreiben IPv6-only-Netze mit Übersetzung für IPv4-Ziele. Entfernen Sie dort IPv6, entfernen Sie den einzigen Transportweg, den das Netz bietet, was einen weit schlimmeren Ausfall erzeugt als den, den Sie gerade untersuchten.

Hat der Ausgang kein IPv6, blockieren Sie es bewusst

Bevorzugen Sie den Mechanismus des Clients selbst, denn er greift genau so lange, wie der Tunnel steht, und wird zurückgenommen, wenn er fällt. OpenVPN hat dafür eine Option, und iptables hat eine gleichwertige Regel für andere Clients:

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

Die Anweisung gehört ins Profil; die Regel gehört in eine Firewall, die Sie prüfen und entfernen können. Beide schlagen geschlossen fehl, was Sie wollen, und beide sind in einem Konfigurationsdiff sichtbar, was ein in ein Startskript vergrabenes Kernel-Sysctl nicht ist.

Halten Sie fest, warum sie da ist. Eine Blockierregel ohne Kommentar wird von der nächsten Person entfernt, die IPv6 für etwas anderes braucht, und dann kehrt das Leck still zurück.

Trägt der Ausgang IPv6, routen Sie es und testen Sie beide Familien

IPv6 zu tragen ist die bessere Antwort, wenn der Server es unterstützt, und es ist nicht viel schwieriger. Voraussetzung ist, dass die Tunnelschnittstelle eine Adresse in dieser Familie hat und die Standardroute dafür in den Tunnel zeigt statt aus der physischen Schnittstelle heraus:

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

Die Routensuche ist der entscheidende Test: nennt sie die Tunnelschnittstelle, wird IPv6-Verkehr getragen. Die beiden curl-Aufrufe bestätigen dann, was jede Familie sieht, und der Vergleich zeigt, dass beide Wege nun über denselben Ausgang verlassen.

Hören Sie nicht bei einer erfolgreichen Verbindung auf. Verbinden Sie den Tunnel neu und prüfen Sie erneut, denn eine gepushte IPv6-Route kann beim Neuaufbau verloren gehen, wenn der Server sie nur in der Anfangskonfiguration sendet. Prüfen Sie dann ein ausgeschlossenes Ziel, denn Split-Tunnel-Regeln sind der Ort, an dem die beiden Familien am häufigsten auseinandergehen.

Ist das Zugangsnetz nur IPv6, lassen Sie es in Ruhe

Manche Netze bieten nur IPv6 und erwarten, dass das Gerät IPv4-Dienste über einen Übersetzungsmechanismus auf der Betreiberseite erreicht. IPv6 auf so einer Maschine abzuschalten ist keine Sicherheitsverbesserung; es entfernt die einzige Route zu irgendetwas. Das ist ein selbst verursachter Ausfall zugunsten eines Testergebnisses, das niemand brauchte.

Das Symptom dieses Fehlers ist unverwechselbar und unangenehm: Der Tunnel scheint sich aufzubauen, die Namensauflösung funktioniert, und nichts lädt. Wenn Sie das nach einer IPv6-Änderung sehen, stellen Sie die Einstellung sofort wieder her und setzen Sie die Diagnose anderswo fort.

Was immer Sie wählen, halten Sie die Entscheidung im Profil oder in der Firewall explizit, binden Sie sie an das, was der Ausgang tatsächlich unterstützt, und notieren Sie das Dual-Stack-Verhalten, das die RFC-7359-Diskussion zum Dual Stack beschreibt. Eine erklärte Blockade ist eine Richtlinie. Ein abgeschaltetes Protokoll ist ein Workaround, den niemand prüfen kann, und von der Testseite sehen beide gleich aus.