Ihr VPN-DNS-Fallback: wohin die Anfrage wirklich geht

Eine Resolver-Einstellung springt von der privaten Adresse auf eine öffentliche, und das Fazit folgt sofort: Der Tunnel leckt. Manchmal stimmt das. Oft reiste die Ausweichanfrage weiterhin innerhalb des Tunnels zu einem Resolver, den der Administrator gewählt hatte, was daraus eine Richtlinienentscheidung statt eines Defekts macht. Diese Fälle zu trennen erfordert drei Tatsachen statt einer, und die erste davon ist, wer geantwortet hat. Finden Sie heraus, wer die Anfrage erhielt, welche Route sie trug und nach welchen Namen gefragt wurde.

Fallback ist eine Richtlinie, kein einzelnes Verhalten

Jeder Client muss entscheiden, was er tut, wenn der bevorzugte Resolver nicht mehr antwortet. Er kann die Auflösung blockieren, es erneut versuchen, eine konfigurierte Alternative verwenden oder dies dem Betriebssystem überlassen, und das sind aus Datenschutzsicht vier verschiedene Produkte. Der Einstellungsbildschirm sagt Ihnen, welches Verhalten konfiguriert ist; er sagt Ihnen nicht, welches eingetreten ist. Ein Bildschirm mit einem einzigen Schalter beschreibt nicht vier Möglichkeiten.

Browser fügen ihre eigene Ebene hinzu. Ein Browser mit aktiviertem sicheren DNS kann einen Namen über seinen eigenen gewählten Anbieter auflösen, selbst wenn das Betriebssystem woanders hin zeigt, was bedeutet, dass die Richtlinie des Tunnel-Clients für die Anfragen, die Ihnen wirklich wichtig sind, möglicherweise nie befragt wird. Prüfen Sie die Anwendung, die die Anfrage gestellt hat, nicht nur die Systemeinstellung.

Die Identität des Ersatz-Resolvers ist die erste Tatsache, die es zu klären lohnt. Ein öffentlicher Resolver eines Anbieters, dem Sie bereits vertrauen, ist eine andere Situation als eine Adresse, die das Netzwerk bereitstellt, in dem Sie sich gerade befinden. Die Adresse selbst verrät selten, welchen der beiden Sie vor sich haben.

Wer die Anfrage nach dem Wechsel erhält

Empfänger und Route sind unabhängig, und nur ihre Kombination beschreibt die Exposition. Ein über den Tunnel erreichter öffentlicher Resolver sieht Ihre Zugangsnetzadresse nie, während derselbe Resolver direkt erreicht sie sieht. Beide Fälle liefern eine Antwort, und ein Lecktest, der nur die Resolver-Adresse meldet, beschreibt sie identisch. Fragen Sie beim Lesen des Ergebnisses nach der Schnittstelle sowie nach der Adresse.

Interne Namen machen den Unterschied konkret. Ein öffentlicher Resolver kann einen Split-Horizon-Namen normalerweise nicht beantworten, sodass die Anfrage scheitert, während der Name dennoch einer Partei offenbart wurde, die ihn nichts angeht. Verfügbarkeit und Datenschutz gehen hier also zusammen, statt gegeneinander abgewogen zu werden.

Ein Tunnel kann die Anfrage auch zu einem Resolver tragen, der nicht vom VPN-Anbieter betrieben wird, denn der Tunnel leitet weiter, statt aufzulösen. Der weiterleitende Host sieht die Anfrage im Klartext und öffnet dann seine eigene Verbindung weiter, was den nächsten Hop schützt, ohne den ersten zu schützen.

Prüfen Sie Route und Empfänger zusammen

Beobachten Sie die Pakete statt der Konfiguration. Fragen Sie das System, welcher Resolver verwendet würde, und bestätigen Sie dann, dass die Anfrage tatsächlich von der erwarteten Schnittstelle zur erwarteten Adresse ging.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Zeigt die Aufzeichnung, dass die Anfrage die physische Schnittstelle verlässt, während der Tunnel aktiv ist, hat der Fallback den Tunnel umgangen, unabhängig davon, was die Resolver-Liste sagt. Erscheint sie auf der Tunnel-Schnittstelle, wird die Frage, wer das ferne Ende betreibt und was es behält.

Wiederholen Sie die Prüfung für einen internen und einen öffentlichen Namen. Bei der internen Anfrage offenbart sich eine Fallback-Konfiguration meist, weil ein Resolver, der nicht antworten kann, die Frage trotzdem erhält.

Entscheiden Sie, ob der Fallback erlaubt sein soll

Wenn die Anforderung ist, dass die Auflösung stoppt, sobald der bevorzugte Resolver nicht verfügbar ist, konfigurieren Sie eine Durchsetzungsrichtlinie, die geschlossen fehlschlägt, und akzeptieren Sie die Folge: Namen werden während eines Ausfalls nicht aufgelöst. Das ist ein bewusster Verfügbarkeitskompromiss und keine Fehlfunktion, und das Design sollte das sagen, bevor der Ausfall eintritt.

Wenn die Anforderung nur ist, dass Anfragen den Tunnel nicht verlassen, kann ein über den Tunnel erreichter öffentlicher Resolver akzeptabel sein, sofern der Betreiber und seine Aufbewahrungsrichtlinie verstanden sind. Diese Akzeptanz ist ein Urteil über einen Dritten und keine Aussage über Kryptografie, und sie gehört demjenigen, der die Datenschutzaussage vertritt. Müssen interne Namen weiter funktionieren, muss der Fallback ein Resolver sein, der die internen Zonen hält, was meist bedeutet, dass das Fallback-Ziel ein anderer Server und keine andere Adressfamilie ist.

Dokumentieren Sie das Ergebnis als einen Satz über das Verhalten: welcher Resolver im Normalbetrieb Anfragen erhält, welcher sie nach einem Ausfall erhält und ob interne Namen im zweiten Fall aufgelöst werden. Ein Lecktest, der schließlich eine Seite lädt, beweist weniger als dieser Satz, denn eine Seite kann über einen Resolver geladen werden, der nie hätte befragt werden dürfen.