Warum ein DNS-Länderetikett kein VPN-Leck beweist
Ein Test ordnet eine Adresse einem Land zu; das sagt wenig über die Route aus. Lies Resolver, Weiterleitungskette und Richtlinie, bevor du etwas änderst.
Ausländisch wirkende Resolver-Adressen tauchen in DNS-Testergebnissen ständig auf, und die Schlussfolgerung, die Menschen daraus ziehen, ist immer dieselbe: Die Abfragen müssen den Tunnel verlassen haben. Manchmal taten sie es. Häufiger beschreibt der Bericht, welcher rekursive Dienst geantwortet hat und wo eine Datenbank diese Adresse vermutet, und das ist eine Aussage über Infrastruktur, nicht über deine Pakete. Beobachtung und Schlussfolgerung zu trennen, erfordert drei Fakten: wer geantwortet hat, wie der Name gereist ist und welche Richtlinie du tatsächlich konfiguriert hast.
Lies, was der Test tatsächlich beobachtet hat
Die meisten Testseiten funktionieren gleich: Sie lassen den Client einen eindeutigen Hostnamen auflösen und schauen dann nach, welcher Resolver ihn geholt hat, oder sie geben einfach die Resolver-Adresse zurück, die der Client meldet. Das identifiziert einen rekursiven Dienst und, wenn die Abfrage Client-Subnetz-Informationen trug, eine grobe Netzwerkposition. Es beweist nicht, dass die Abfrage das Gerät außerhalb des Tunnels verlassen hat, und schon gar nicht, dass für jeden Namen derselbe Pfad verwendet wurde. Eine einzelne Beobachtung einer Abfrage wird zu einer Aussage über den gesamten Datenverkehr verallgemeinert.
Ein Test, der die Resolver-Adresse zeigt, ist nützlicher als ein Länderabzeichen, weil sich die Adresse mit der Resolver-Liste vergleichen lässt, die der Client tatsächlich erhalten hat.
Anycast und Weiterleitung erklären die meisten Überraschungen
Große öffentliche Resolver kündigen dieselbe Adresse von vielen Standorten an, und das Netzwerk leitet jede Abfrage an den routingtechnisch nächstgelegenen Standort. Eine Geolokalisierungsdatenbank ordnet diese Adresse dann einem einzigen Ort zu, der eine Firmenteintragungsadresse auf einem anderen Kontinent sein kann oder ein Rechenzentrum, das nicht das antwortende ist. RFC 4786 behandelt die Betriebspraxis für Anycast-Dienste und die Schwierigkeit, eine solche Adresse einem einzigen physischen Ort zuzuordnen. Die Karte ist eine Vereinfachung einer Routingentscheidung, und sie vereinfacht in die Richtung, die alarmierende Ergebnisse erzeugt.
Weiterleitung fügt eine zweite Ebene hinzu. Ein lokaler Stub-Resolver, ein Router oder ein ISP-Resolver kann Abfragen an einen vorgelagerten Dienst weitergeben, und der Name, der im Test erscheint, spiegelt den letzten Betreiber in dieser Kette wider, nicht den ersten. Client-Subnetz-Erweiterungen können eine Antwort von oben auf dein Netzwerk zuschneiden und gleichzeitig den gemeldeten Standort wie einen Ort aussehen lassen, an dem du noch nie warst.
Ein konfigurierter Resolver kann daher korrekt sein und trotzdem ein ausländisch wirkendes Ergebnis liefern, und ein Resolver im eigenen Land kann der falsche sein, weil er zu einer Partei gehört, die du nicht ausgewählt hast.
Wer den Namen erhielt und über welche Route
Zwei Fragen beantworten den praktischen Teil: Welchen Server nutzt der Client, und wird dieser Server durch den Tunnel erreicht. Vergleiche die Resolver-Liste mit der Adresse im Testergebnis, bevor du Schlüsse über das Routing ziehst, und prüfe dann, ob die Abfrage an diese Adresse über das Tunnel-Interface hinausgeht. Wenn die beiden Adressen abweichen, ist der interessante Befund, dass etwas den vorgesehenen Resolver umgeschrieben oder umgangen hat, was einen genaueren Blick verdient als der Ländername.
resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net
Der erste Befehl zeigt, welcher Server für einen Namen geantwortet hat, der zweite zeigt die konfigurierte Liste und ihren Geltungsbereich, und der dritte meldet die Resolver-Adresse, wie ein öffentlicher Dienst sie sieht. Wenn alle drei übereinstimmen, tut die Richtlinie das, wofür sie konfiguriert wurde, egal was das Länderetikett sagt.
Vergleiche mit der Richtlinie, die du gewählt hast
Ein VPN, das einen Resolver erzwingt, ein Browser, der für sein eigenes verschlüsseltes DNS konfiguriert ist, und ein Betriebssystem, das die Einstellungen einer Schnittstelle bevorzugt, können einzeln korrekt sein und sich dennoch gemeinsam widersprechen. Moderne Browser können Abfragen über einen verschlüsselten Transport an einen im Browser gewählten Anbieter senden, was die Resolver-Liste des Systems bewusst umgeht. Das ist kein Leck im Sinne eines defekten Tunnels; es ist eine anderswo gewählte Richtlinie, und herauszufinden, wo sie gewählt wurde, ist die eigentliche Aufgabe.
Arbeitsgeräte ergänzen domänenspezifische Regeln: interne Namen müssen zum Resolver der Organisation gehen, während alles andere der Vorgabe folgt. Diese Regelung zu ersetzen, weil eine Testseite ein unerwartetes Land zeigte, ist der Weg, auf dem interne Namen für ein ganzes Team nicht mehr aufgelöst werden.
Halte Tests eng und sicher
Eine öffentliche Teststelle nach einem internen Hostnamen zu fragen, offenbart den Namen einer Partei, die nichts damit zu tun hat, und die Antwort sagt dir nichts, was das lokale Lesen der Resolver-Liste nicht auch sagen würde.
Verwende stattdessen Namen, die Infrastruktur offenlegen, protokolliere Resolver-Adresse, Geltungsbereich und verwendete Schnittstelle und vergleiche dieses Protokoll mit der dokumentierten Absicht. Ein Kartenetikett ist Kontext für ein Gespräch und kein Bestanden-oder-Durchgefallen-Ergebnis, und es als Urteil zu behandeln, erzeugt Konfigurationsänderungen statt Diagnose.