Wird das VPN-DNS wirklich genutzt? Port 53 mitschneiden und nachsehen

Fragen Sie die meisten Leute, was ein VPN-Client mit DNS macht, und sie sagen, er setze den Resolver, sodass Abfragen im Tunnel reisen. Der Push ist real; die Annahme, dass daraus eine Abfrage wird, nicht. Zwischen einer gepushten Option und einem Paket auf der Leitung liegen drei Stufen, und jede versagt unabhängig auf Arten, die alle wie ein defekter DNS-Server aussehen. Deshalb können eine Leak-Test-Seite und ein funktionierender Browser sich über denselben Rechner im selben Moment widersprechen.

Eine gepushte Option ist keine Abfrage

Stufe eins ist, dass der Server Einstellungen anbietet, etwa eine gepushte DNS-Option, die einen Resolver im Tunnel benennt. Stufe zwei ist, dass der Client diese Einstellungen auf eine Schnittstelle anwendet. Stufe drei ist, dass eine Anwendung tatsächlich eine Abfrage an diese Adresse sendet. Ein Fehler in Stufe zwei lässt die Option im Verbindungsprotokoll sichtbar, während die Resolverliste unverändert bleibt, und ein Fehler in Stufe drei lässt eine völlig korrekte Resolverliste ungenutzt.

Die meisten Fehlersuchen werfen diese drei in einen Topf und beschuldigen den VPN-Server, der meist die einzige Partei ist, die beweisen kann, dass sie ihren Teil getan hat. Lesen Sie stattdessen den tatsächlichen Resolver-Zustand des Clients und sehen Sie dann zu, wie eine Abfrage hinausgeht. Diese zwei Beobachtungen trennen Konfiguration von Routing und von Policy, und sie kosten etwa fünf Minuten. Heben Sie die Mitschnitte auf, denn der nächste Ingenieur will das Vorher und Nachher statt einer Beschreibung davon.

Prüfen Sie, was die Schnittstelle tatsächlich hält

Unter Linux kann der Systemresolver die einfache Datei, NetworkManager oder systemd-resolved sein, und wer von ihnen sie besitzt, entscheidet, wo ein gepushter Server landet. Ein OpenVPN-Prozess auf der Kommandozeile aktualisiert den Systemresolver nicht von selbst, deshalb ist die dokumentierte Integration ein Up/Down-Skript oder ein Verbindungsmanager, der die Einstellungen bereits anzuwenden weiß. Beides laufen zu lassen ist ein effizienter Weg, ein Wettrennen zu erzeugen.

resolvectl status
cat /etc/resolv.conf

Unter Windows gilt die Liste pro Adapter, sodass der Tunneladapter die internen Server halten kann, während der physische Adapter die lokalen behält und bei manchen Namen gewinnt. Vergleichen Sie beide Adapter statt den, von dem Sie annehmen, dass er aktiv ist.

Verfolgen Sie eine Abfrage aus dem Rechner hinaus

Schneiden Sie beide Schnittstellen gleichzeitig mit und lösen Sie dann einen Namen auf, der den internen Resolver nutzen sollte. Dieses Paar Mitschnitte beantwortet, was keine Konfigurationsausgabe beantworten kann.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Eine Abfrage, die auf der physischen Schnittstelle erscheint und nie im Tunnel, bedeutet, dass der Client den falschen Resolver gewählt hat. Eine Abfrage auf keiner von beiden bedeutet, dass die Anwendung aus dem Cache geantwortet, einen auf Loopback lauschenden Stub gefragt oder einen verschlüsselten Resolver genutzt hat, dessen Verkehr gar nicht als Port 53 erscheint. Schneiden Sie auch Antworten mit, nicht nur Abfragen, denn eine Abfrage, die durch den Tunnel geht und eine Antwort von einer öffentlichen Adresse erhält, ist ein anderer Fehler als eine, die gar keine Antwort bekommt.

Die Firewall, die nur ihr eigenes DNS akzeptiert

Kommerzielle Clients installieren manchmal eigene Filterketten. Ein dokumentiertes Muster erlaubt DNS zum eigenen Resolver des Clients und verwirft den gesamten übrigen UDP-Verkehr auf Port 53, der eine Schnittstelle verlassen will, die nicht Loopback ist, einschließlich Verkehr, den der Nutzer absichtlich woandershin geroutet hat. Dämon-Abfragen verschwinden spurlos, was als Resolver-Fehler statt als Filter gelesen wird.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Wird eine Verwerfungsregel vor Ihrer Ausnahme ausgewertet, wird eine angehängte Regel nie erreicht, also fügen Sie sie an erster Position ein und beschränken Sie das Ziel auf den Resolver, den Sie wirklich meinen.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Diese Ausnahme ist diagnostisch und nicht Politik. Ist die Regel des Anbieters beabsichtigt, besteht die unterstützte Reparatur darin, den Client so zu konfigurieren, dass er diesen Resolver zulässt, und die Entscheidung festzuhalten, denn eine eingefügte Regel überlebt das nächste Client-Upgrade nicht.

Warum eine Leak-Seite weniger beweist, als es scheint

Was eine Leak-Test-Seite zeigt, ist der Resolver, der mit dem Testbetreiber gesprochen hat, nicht der, den Ihr Rechner gefragt hat. Ein lokaler Forwarder, der nach außen rekursiert, setzt seine eigene Ausgangsadresse auf diese Seite, und verschlüsselte Abfragen können die Seite völlig leer lassen. Beide Ergebnisse werden falsch gelesen, das eine als Leck und das andere als Garantie, und keine der beiden Lesarten folgt aus der Beobachtung.

Der belastbare Beweis ist der Mitschnitt: Schnittstelle, Zieladresse, Antwort und Zeitstempel. Nehmen Sie einen auf, bevor der Tunnel hochkommt, und einen danach, und vergleichen Sie sie, wenn das nächste Mal ein Name scheitert. Dieses Paar sagt der nächsten Person auch, ob der Fehler in der Auflösung, im Routing oder in der Zugriffsrichtlinie des Resolvers lag.