Wohin DNS geht, wenn Sie Tor und ein VPN kombinieren

Zwei Datenschutzwerkzeuge laufen, eine Seite lädt nicht, und ein Resolver-Test sagt, dass etwas außerhalb des Browsers einen Namen erhalten hat. Bevor daraus ein Leck-Bericht wird, benennen Sie den Austausch, aus dem er stammt. Ein Aufbau aus Tor plus VPN enthält mindestens drei verschiedene Namensabfragen mit drei verschiedenen Eigentümern, und sie in der Reihenfolge zu durchgehen, in der sie stattfinden, ist der schnellste Weg zu sehen, welcher sich falsch verhält.

Benennen Sie jeden Austausch, bevor Sie von einem Leck sprechen

Der erste Austausch löst den VPN-Endpunkt selbst auf, und er geschieht, bevor irgendein Schutz existiert. Der zweite löst ein Ziel für den Tor Browser auf, der den Namen an den Proxy weiterreichen kann, statt ihn lokal aufzulösen. Der dritte deckt alles andere auf dem Rechner ab, einschließlich Update-Prüfungen, Mail-Clients und der Dienstabfragen des Betriebssystems selbst. Nur der erste davon kann geschehen, ohne dass die anderen beiden beteiligt sind.

Jeder davon kann einem anderen Weg folgen, und ein einzelner browserbasierter Test beobachtet nur seine eigene Anfrage. Ein Ergebnis als Zustand aller drei zu behandeln, ist der Punkt, an dem die meiste Verwirrung beginnt.

Schreiben Sie auf, welche Namen zu welcher Schicht gehören, bevor Sie etwas ändern. Private Organisationsnamen, ein öffentliches Ziel und der Tunnel-Endpunkt selbst tragen nicht dieselbe Anforderung, und eine Richtlinie, die sie als eine Kategorie behandelt, wird etwas kaputt machen.

Die Bootstrap-Abfrage geschieht vor dem Tunnel

Ein mit einem Hostnamen konfigurierter Client muss diesen Namen auflösen, um den Tunnel zu öffnen, und in diesem Moment existiert kein Tunnel, der die Abfrage tragen könnte. Es antwortet welcher Resolver auch immer das Betriebssystem im aktuellen Netz anbietet, was ein Captive Portal, ein Hotel-Resolver oder ein öffentlicher sein kann. Das ist kein Leck im Tunnel, denn es gibt noch keinen Tunnel.

Die sichere DNS-Einstellung des Browsers zu ändern, berührt diese Abfrage ebenfalls nicht, da sie zu einem Dienst gehört, der außerhalb des Browsers läuft und startet, bevor irgendeine Seite geöffnet wird. Wenn der Endpunktname nicht aufgelöst werden kann, hilft keine Richtlinie im Tunnel, weil der Fehler eine Stufe früher auftritt als alles, was die Konfiguration beschreibt.

Dies ist die eine Stelle, an der die Verwendung einer wörtlichen Adresse für den Endpunkt, wenn der Anbieter sie unterstützt, eine Abhängigkeit entfernt statt hinzuzufügen. Sie entfernt auch die Möglichkeit, einem Anbieter zu folgen, der Adressen rotiert, also ist der Tausch real und sollte entschieden statt entdeckt werden.

Der Browser und der Rest des Rechners unterscheiden sich

Die SOCKS-Schnittstelle von Tor unterstützt das Weiterreichen eines Ziel-Hostnamens an den Proxy, was bedeutet, dass die Gegenseite die Auflösung durchführt und der lokale Rechner nie fragt. Eine generische Anwendung, die einen Proxy unterstützt, kann den Namen zuerst lokal auflösen und dann die erhaltene Adresse verbinden, was eine lokale Abfrage für ein Ziel erzeugt, das der Nutzer für proxied hielt. Die beiden Anwendungen können daher an verschiedenen Stellen lecken, während sie eine Proxy-Einstellung teilen. Nichts an einer geteilten Proxy-Adresse sagt Ihnen, welches der beiden Verhalten in Gebrauch ist.

Browser fügen eine weitere Ebene hinzu, wenn sicheres DNS aktiviert ist, weil der Browser seinen eigenen Anbieter wählen und den System-Resolver vollständig umgehen kann. Der Tunnel-Client kann unterdessen einen Resolver durch den Tunnel für den ganzen Rechner schieben. Diese beiden Einstellungen können beide korrekt sein und dennoch unterschiedliches Verhalten für unterschiedliche Programme beschreiben.

Prüfen Sie das Programm, das die Anfrage gestellt hat, statt von einer Testseite zu extrapolieren. Der Unterschied zwischen einer im Tunnel getragenen Abfrage und einer, die Tor nie erreichte, ist genau der Unterschied, den eine einzelne Resolver-Adresse nicht zeigen kann.

Prüfen Sie jedes Programm und vergleichen Sie dann mit der Absicht

Führen Sie die Beobachtungen getrennt durch: was das System verwenden würde, wofür der Browser konfiguriert ist und ob die SOCKS-Verbindung einen Namen oder eine Adresse trägt. Letzteres ist der Unterschied zwischen entfernter und lokaler Auflösung, und SOCKS-Erweiterungsspezifikation beschreibt, wie ein Hostname weitergegeben statt zuerst aufgelöst wird.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Vergleichen Sie dann das Beobachtete mit dem Beabsichtigten. Ein öffentlicher Name, der durch den Tunnel von einem von Ihnen gewählten Resolver aufgelöst wird, ist nicht derselbe Befund wie ein privater Name, der während eines Rückfalls an einen öffentlichen Resolver gegeben wird, und nur der zweite erfordert normalerweise Handeln. Der erste ist eine Konfiguration, die wie entworfen funktioniert, auch wenn sie in einem Bericht ungewohnt aussieht.

Halten Sie die Ausnahmen fest, die Sie akzeptieren, einschließlich der Bootstrap-Abfrage, die nicht geschützt werden kann. Eine aufgeschriebene Ausnahme ist eine Designentscheidung, während dieselbe Ausnahme, später entdeckt, wie ein Defekt aussieht. Wer sie findet, wird sie als solchen behandeln, und Sie werden das Meeting damit verbringen zu erklären, warum sie es nicht ist.