Ein reines IPv6-Netz bricht das VPN, bevor der Tunnel startet

Das Notebook verbindet sich mit einem Konferenz-WLAN, das nur IPv6 verteilt, der VPN-Client dreht sich und scheitert, und dasselbe Profil lief eine Stunde zuvor in einem Hotel. An den Zugangsdaten hat sich nichts geändert. Geändert hat sich, dass der Client nun ein IPv4-Ziel über ein Netz erreichen muss, das nur IPv6 trägt, und nicht jeder Client weiß, wie das geht.

Gehen Sie dieselben fünf Schritte, die die Pakete gehen.

Schritt 1: die Namensauflösung beobachten

Nutzt das Profil einen Hostnamen, ist die erste Frage, was der Resolver zurückgibt. dig AAAA vpn.example.com liefert im reinen IPv6-Netz einen echten AAAA-Eintrag, einen aus DNS64 synthetisierten oder gar nichts. Eine synthetisierte Antwort kodiert das IPv4-Ziel in einem Übersetzungspräfix, und erst dann kann ein Client ohne IPv6-Ziel es erreichen. Ein Profil mit fest eingetragener IPv4-Adresse kommt nie so weit, weil es keinen Namen zu synthetisieren gibt.

Dieser eine Unterschied erklärt die meisten »dort geht es, hier scheitert es«-Meldungen, und ein einziger Befehl zeigt ihn.

Schritt 2: sehen, welche Familie der Client gewählt hat

Beobachten Sie den Socket statt des Fortschrittsbalkens. Ein Client, der auf einer reinen IPv6-Strecke einen IPv4-Socket zu einer IPv4-Adresse öffnet, hat kein Ziel dafür, und der Fehler zeigt sich als Zeitüberschreitung statt als Namensfehler. ss -tanp zeigt während des Verbindungsaufbaus die Gegenstelle und die Familie, die versucht wurde. Vergleichen Sie das mit ip -6 route, um zu bestätigen, dass die Voreinstellung ein echter IPv6-Nexthop ist.

Die Adressfamilie in der Socket-Tabelle ist die Tatsache. Der Fortschrittsbalken ist eine Zusammenfassung, die jemand anderes geschrieben hat.

Schritt 3: Übersetzung vom Tunnel trennen

NAT64 und DNS64 sind der Weg, auf dem das Zugangsnetz IPv4-Ziele erreicht, und sie tun nichts für den Tunnel, sobald er steht. Ein Tunnel über einen übersetzten Pfad handelt weiterhin seine eigene innere Adressierung aus, und die innere IPv4- oder IPv6-Abdeckung ist eine separate Richtlinienfrage. Wenn der Client sich verbindet und dann nichts erreicht, sind Sie über die Übersetzung hinaus und im Routing, was eine andere Untersuchung mit anderen Belegen ist.

Scheiternde Übersetzung sieht aus wie nie verbinden. Scheiternde innere Abdeckung sieht aus wie verbinden und nichts erreichen.

Schritt 4: dasselbe Profil in einem anderen Netz testen

Nehmen Sie dasselbe Profil, dieselbe Client-Version und dieselben Zugangsdaten in ein Dual-Stack-Netz und wiederholen Sie es. Funktioniert es dort und scheitert auf dem reinen IPv6-Pfad, ist die Variable das Zugangsnetz und nicht das Profil. Notieren Sie Client-Version und Netzbedingung im Ticket, denn die endgültige Lösung ist ein Client-Update oder ein anderes Ziel.

Eine Meldung, das VPN sei kaputt, ist nicht handhabbar. Eine Meldung, es scheitere nur bei reinem IPv6-Zugang, ist eine Fehlermeldung.

Schritt 5: den Pfad reparieren, nicht die Sicherheitseinstellungen

Die naheliegenden Reparaturen machen alles schlimmer. IPv6 abzuschalten entfernt den einzigen Pfad, den das Netz bietet. Den Client auf einen öffentlichen Resolver zu zeigen bricht die DNS64-Synthese, weil diese Synthese vom Resolver hinter dem Übersetzer kommen muss. Die Zertifikatsprüfung abzuschalten verschafft Ihnen eine Verbindung zu etwas, das Sie nicht identifizieren können. Nichts davon ist eine Reparatur, und zwei davon sind Sicherheitsregressionen, die den Vorfall überleben werden.

Die echten Optionen sind ein Client, der das Netzübersetzungsmodell unterstützt, oder ein Ziel mit einer erreichbaren IPv6-Adresse. Bitten Sie um eines davon.