Dual-Stack-VPN: Der Client wählt die Adressfamilie, nicht Sie

Ein Name, zwei Familien, zwei verschiedene Wege. Der Tunnel kann gesund sein und die Anfrage trotzdem scheitern, weil der Client einen Kandidaten gewählt hat, den Sie nie geroutet haben.

Der Tunnel steht, IPv4-Seiten laden, und ein Hostname läuft in eine Zeitüberschreitung. Die naheliegende Schlussfolgerung ist, dass das VPN defekt oder die Zugangsdaten falsch sind, und beides trifft meist nicht zu. Der Name lieferte sowohl eine IPv4- als auch eine IPv6-Adresse, die Anwendung wählte eine davon, und nur einer dieser Kandidaten hatte einen funktionierenden Pfad. Die Auswahlentscheidung traf der Client; der Tunnel deckte einfach nicht ab, was er ausgewählt hatte.

Auswahl ist kein Versprechen von Abdeckung

Die Standardadressauswahl nach RFC 6724 entscheidet, welches Quell- und Zielpaar ein Host bevorzugt, wenn mehrere verfügbar sind. Happy Eyeballs legt eine Verbindungsstrategie darüber: Es startet Versuche in beiden Familien und behält den, der zuerst antwortet, damit ein Benutzer nicht auf eine defekte Familie wartet, bis sie ausläuft.

Keiner der Mechanismen erzeugt eine Route. Trägt Ihr Tunnel nur IPv4, ist ein AAAA-Kandidat weiterhin ein legitimes Ziel, das der Client versuchen darf, und der Fehler zeigt sich als langsames Laden statt als Fehler, weil der Browser zurückgefallen ist. Der Benutzer meldet eine langsame Seite, keine defekte, und das Support-Ticket erbt diese Unschärfe. Reproduzieren Sie es mit einer festen Familie, und der Bericht wird konkret.

Wegen dieses Rückfalls ist das Symptom über Anwendungen hinweg uneinheitlich. Ein Browser verbirgt die Verzögerung; ein Kommandozeilen-Client mit fester Familie zeigt Ihnen den echten Fehler sofort.

Finden Sie die Familie, die die Anfrage tatsächlich verwendet hat

Beginnen Sie mit dem Namen, nicht mit dem Tunnel. Fragen Sie beide Datensatztypen ab und notieren Sie, was zurückkam:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Gelingt die v4-Anfrage und scheitert die v6-Anfrage, haben Sie das Problem in einer debuggaren Form reproduziert. Gelingen beide in der Shell und scheitert der Browser weiterhin, prüfen Sie den eigenen Resolver der Anwendung oder eine zwischengespeicherte Antwort, bevor Sie den Tunnel anfassen.

Halten Sie Familie und Ziel in Ihren Notizen fest. Ein Ticket, das sagt, die Seite lade nicht über das VPN, kann niemand prüfen, während ein Ticket, das sagt, AAAA scheitere und A funktioniere, auf eine bestimmte Route zeigt.

Prüfen Sie die Route für diese Familie

Fragen Sie für die fehlschlagende Familie den Kernel, welchen Pfad er verwenden würde, und vergleichen Sie ihn mit den konfigurierten Adressen des Tunnels. Unter Linux zeigt ip -6 route get für das Ziel die Schnittstelle und die Quelle an, die ausgewählt würden.

Prüfen Sie dann den Tunnel selbst. WireGuard-Peers führen eine Liste erlaubter IPs, und ein Eintrag für 0.0.0.0/0 sagt nichts über IPv6 aus. Hat die Liste des Peers kein IPv6-Präfix, hat der Client keinen Grund, AAAA-Verkehr in den Tunnel zu schicken, und das Paket verlässt den Host über das, was er sonst tun würde.

Firewall-Regeln und NAT-Richtlinien verdienen dieselbe Prüfung pro Familie. Eine für IPv4 geschriebene Regel deckt IPv6 auf keiner Plattform ab, und das ist der häufigste Grund, warum eine Familie funktioniert und die andere nicht.

Deaktivieren Sie IPv6 nicht, um den Screenshot einfach zu halten

IPv6 systemweit abzuschalten lässt das Symptom verschwinden und lässt Sie ohne Diagnose zurück. Es bricht außerdem jedes Ziel, das nur IPv6 spricht, und verbirgt denselben Fehler für die nächste Anwendung. Wenn eine Maschine wirklich kein IPv6 nutzen soll, ist das eine bewusste Richtlinie mit einem Verantwortlichen und einem Test. Das Abschalten während eines Vorfalls ist beides nicht.

Entscheiden Sie, was der Client mit der Familie tun soll, und konfigurieren Sie das ausdrücklich: Tragen Sie sie durch den Tunnel, oder blockieren Sie sie auf unterstützte Weise, sodass die Auswahl nie einen unerreichbaren Kandidaten anbietet. Beides sind legitime Entwürfe. Eine globale Deaktivierung ist keiner davon, denn sie ist überhaupt kein Entwurf.

Was in das Ticket gehört

Notieren Sie vier Dinge: den Hostnamen, die Familie, die fehlgeschlagen ist, die Route, die der Kernel gewählt hat, und das Ergebnis einer familienspezifischen Anfrage. Diese Angaben genügen, damit jemand anderes den Fehler reproduzieren kann, ohne zu raten, welchen der beiden Wege Sie meinten.

Die Regeln zur Adressauswahl nach RFC 6724 erklären, warum der Client den Kandidaten bevorzugte, den er bevorzugte, und RFC 8305 erklärt das Wettlaufverhalten, das die Verzögerung verbarg. Keines von beiden wird ein Paket für Sie routen, und genau das muss der Tunnel leisten.

Ähnliche Artikel