Warum ändern sich DNS64-Antworten, sobald das VPN verbindet?

Eine DNS64-Antwort kodiert eine Übersetzungsannahme. Prüfen Sie, welcher Resolver geantwortet hat, ob das Präfix geroutet wird und ob ein Übersetzer auf Ihrem Pfad sitzt.

DNS64-Antworten beschreiben eine Netzwerkanordnung und keine Eigenschaft des Servers. Der Resolver synthetisiert eine IPv6-Adresse aus einer IPv4-Adresse, und das Ergebnis funktioniert nur dort, wo am Ende dieses Präfixes ein Übersetzer sitzt. Bringen Sie ein VPN in den Pfad, und diese Anordnung kann halten, sich ändern oder aufhören zu stimmen, je nach drei Bedingungen.

Diese Bedingungen sind der Resolver, der geantwortet hat, die Route, die Ihr Gerät zum synthetisierten Präfix hat, und ob irgendetwas auf dieser Route die Übersetzung vornimmt. Jede davon ist beobachtbar, und genau das macht den Fehler diagnostizierbar.

Worauf ein synthetisierter AAAA-Eintrag tatsächlich zeigt

Ein DNS64-Resolver beantwortet eine AAAA-Abfrage für einen reinen IPv4-Namen, indem er die IPv4-Adresse in ein Präfix einbettet, für dessen Verwendung er konfiguriert ist, und das wohlbekannte Präfix für diese Aufgabe ist 64:ff9b::/96, wie in RFC 6147 beschrieben. Für die Anwendung sieht der Eintrag wie jeder andere AAAA-Eintrag aus, und das ist der Punkt: Ein reiner IPv6-Client kann eine Verbindung versuchen, ohne zu wissen, dass das Ziel nie IPv6 hatte. Diese Verbindung hängt dann von einer NAT64-Funktion ab, die irgendwo auf dem Pfad zwischen den beiden Familien übersetzt. Ohne diesen Übersetzer ist die synthetisierte Adresse ein glaubwürdig wirkendes Ziel, das nirgendwohin führt.

Der Eintrag kodiert also zwei Dinge zugleich: die ursprüngliche IPv4-Adresse und die Annahme, dass ein Übersetzer erreichbar ist. Nur das erste ist in der Antwort selbst sichtbar.

Drei Bedingungen entscheiden, ob es noch funktioniert

Die erste Bedingung ist, welcher Resolver den Eintrag erzeugt hat, denn einer ohne konfiguriertes DNS64 liefert für diesen Namen nichts und die Anwendung scheitert auf andere Weise. Die zweite ist, ob Ihr Gerät eine Route zum synthetisierten Präfix hat, denn eine Antwort kann gültig sein, während der Pfad dorthin fehlt. Die dritte ist, ob der Übersetzer, dem dieses Präfix gehört, auf dem Pfad liegt, den Sie nutzen würden, denn ein Tunnel, der 64:ff9b::/96 woandershin trägt, erreicht eine andere Funktion oder gar nichts. Alle drei können vor dem Tunnel gelten und danach scheitern, und deshalb wirkt das Symptom wie eine plötzliche Regression.

Prüfen Sie sie in dieser Reihenfolge. Eine fehlende Antwort und eine fehlende Route sehen im Browser gleich aus und im Resolver-Log völlig unterschiedlich.

Ändert sich der Resolver, ändert sich die Antwort

Ein VPN-Client schiebt häufig seinen eigenen Resolver durch oder übernimmt den gesamten Abfragepfad, und dieser Resolver synthetisiert möglicherweise nichts. Abfragen für reine IPv4-Namen liefern dann keinen AAAA-Eintrag, was ein reiner IPv6-Client als einen Namen erlebt, den er nicht erreichen kann. Der umgekehrte Fall kommt auch vor: Ein Resolver, der tatsächlich synthetisiert, kann Ihnen ein Präfix geben, das Ihr getunnelter Pfad nicht trägt.

Caching macht das schwerer sichtbar. Ein im Büronetz bezogener synthetisierter Eintrag kann den Kontext überleben, der ihn erzeugt hat, sodass der Client weiterhin eine Adresse verbindet, deren Übersetzer nicht mehr erreichbar ist. Schauen Sie auf den Resolver, der jetzt antwortet, statt auf den, der antwortete, als der Eintrag gespeichert wurde. Den Cache zu leeren, ohne die alte und die neue Antwort festzuhalten, zerstört den Beweis, den Sie brauchen.

Testen Sie die Abfrage und den Pfad getrennt

Fragen Sie den Namen direkt ab, bevor Sie die Anwendung einbeziehen, und notieren Sie, welcher Server geantwortet hat. Die Befehle unten zeigen den AAAA-Eintrag, den verwendeten Resolver und ob eine Route zum synthetisierten Präfix existiert. Führen Sie sie mit abgebautem Tunnel aus und erneut mit aufgebautem.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Lesen Sie die Ergebnisse als Kette. Ein fehlender AAAA-Eintrag bedeutet, dass der Resolver vor Ihnen nicht synthetisiert, also wird ein reiner IPv6-Pfad für diesen Namen nicht funktionieren, was der Client auch tut. Ein vorhandener Eintrag ohne Route bedeutet, dass das Präfix vom aktuellen Pfad nicht getragen wird, und das ist eine Routing-Entscheidung und kein Resolver-Fehler. Eine vorhandene Route, während die Anfrage weiterhin scheitert, deutet auf den Übersetzer selbst hin, und der gehört einem weiteren Eigentümer.

Notieren Sie Resolver, Netzkontext und Adressfamilie neben jedem Ergebnis. Diese Notiz ist es, die den nächsten Vergleich einen Resolver-Wechsel von einem Routing-Wechsel trennen lässt.

Ähnliche Artikel