Warum dnsmasq-Anfragen die VPN nach einer DNS-Umleitung verlassen

Der LAN-Client erreicht seine VPN korrekt, und trotzdem erscheinen seine DNS-Anfragen auf dem falschen Uplink. Das ist kein Leck im üblichen Sinn; es ist das, was passiert, wenn der Router aufhört, eine Anfrage weiterzuleiten, und sie selbst beantwortet. Die Abfangung schreibt das Ziel auf einen lokalen Socket um, und der Resolver öffnet dann ein zweites, unabhängiges Gespräch mit seiner eigenen Quelladresse und seiner eigenen Routing-Entscheidung. Markierungen am Client-Flow beschreiben das erste Gespräch und überhaupt nichts über das zweite.

Die Markierung reist nicht mit der Anfrage

Paketmarkierungen leben an einem conntrack-Eintrag und am Paket im Flug. Eine REDIRECT-Regel beendet diesen Flug: Die Nutzlast wird an einen lokalen Socket übergeben, und der ursprüngliche Eintrag hat seine Aufgabe erfüllt. Was den Router danach verlässt, ist ein frischer Socket, den der Resolver-Prozess erzeugt hat, mit der Adresse des Routers selbst als Quelle.

Deshalb trifft eine Policy-Route, die auf die Adresse des LAN-Clients abgestellt ist, nie die Upstream-Anfrage. Der neue Socket gehört dnsmasq und nicht dem Client, und der Kernel bewertet die Route für den Verkehr des Routers selbst. Quellregeln, Interface-Regeln und Markierungsregeln sehen alle ein anderes Tupel. Die Annahme, die Markierung werde fortgepflanzt, ist der häufigste Fehler in diesem Aufbau, und sie ist in einem Mitschnitt auf Client-Seite unsichtbar.

Die beiden Gespräche teilen sich tatsächlich einen Namen und einen Zeitpunkt, und genau das lässt sie wie einen einzigen Flow aussehen, wenn man einen Mitschnitt überfliegt.

Wo aus Weiterleitung lokale Auflösung wird

Finden Sie zuerst heraus, ob Port 53 umgeleitet, auf einen anderen Host übersetzt oder unangetastet bleibt, denn die drei Fälle verhalten sich unterschiedlich. Eine Umleitung auf einen lokalen Port beendet die Weiterleitung, während eine Übersetzung auf eine andere Maschine das Paket in Bewegung hält und das Tupel des Clients sinnvoll lässt.

Betrachten Sie beide Protokolle. Ein über UDP und TCP erreichbarer Resolver wird über beide getestet, und ein Regelsatz, der nur UDP abdeckt, lässt ein stilles Loch für große Antworten. Regeln, die der Konfigurationsmanager des Routers selbst erzeugt, zählen ebenfalls, und das Bearbeiten einer erzeugten Datei verliert meist gegen den nächsten Reload.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Diese Ausgaben beantworten drei Fragen der Reihe nach: was die Anfrage umschreibt, was sie empfängt und welcher Prozess den lauschenden Socket besitzt. Sobald der Besitzer bekannt ist, hat die Upstream-Policy einen Platz zum Leben.

Geben Sie dem Resolver eine eigene Ausgangspolicy

Ein domänenspezifischer Upstream ist das sauberste Werkzeug, wenn nur einige Namen den Tunnel brauchen. dnsmasq akzeptiert eine auf eine Domäne begrenzte server-Zeile, mit einem optionalen Interface oder einer Quelladresse, die die Anfrage aus einem gewählten Gerät herauslenkt. Diese Lenkung ist es, die das zweite Gespräch der VPN folgen lässt.

server=/corp.example/10.30.0.53@tun_work
log-queries

Domäne, Adresse und Interface oben sind Platzhalter für Ihre eigenen Werte. Domänenauswahl und Ausgangskontrolle bleiben getrennte Entscheidungen: Die Route muss existieren, die Quelladresse muss vom Upstream-Resolver erlaubt sein, und die Firewall muss die Antwort zulassen. Interface-Lenkung allein ist nicht fail-closed, weil ein verschwundener Tunnel den Resolver auf einen anderen Pfad zurückfallen lassen kann. Halten Sie jeden öffentlichen Rückfallweg fern von einem Namensraum, der privat bleiben muss.

Legen Sie die Zeile beim Konfigurationseigentümer ab, den der Router unterstützt, statt in einer erzeugten Datei, sonst löscht der nächste Reload die Korrektur.

Was ein gemeinsamer Cache nicht bewahren kann

Ein Forwarder mit einem Cache bedient jeden LAN-Client, und das bricht eine Unterscheidung zusammen, die manche Netze brauchen. Wenn zwei Clients denselben Namen unterschiedlich auflösen müssen, hat der gemeinsame Socket keine Möglichkeit, den fragenden Client wiederzugewinnen. Policy pro Client muss in getrennten Resolver-Instanzen leben oder in einer Weiterleitungsfunktion, die die Identität behält.

Eine zwischengespeicherte Antwort ist auch kein Beleg für den neuen Pfad. Die Antwort kann aus dem Speicher kommen, während die Upstream-Route kaputt bleibt.

Port-53-Regeln sagen nichts über Anwendungen, die DNS über HTTPS oder über TLS sprechen. Diese Anfragen erreichen die Umleitung nie, also beschreibt eine Policy, die nur auf Port 53 aufbaut, eine Teilmenge des Verkehrs und sollte als Teilmenge dokumentiert werden.

Prüfen Sie das zweite Gespräch, nicht das erste

Testen Sie mit einem Namen, den Sie kontrollieren, und beobachten Sie beide Seiten. Ein Mitschnitt auf Client-Seite beweist, dass die Anfrage das LAN verlassen hat; nur die Router-Seite beweist, wohin sie als Nächstes ging.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Leeren Sie den Cache vor jedem Versuch, denn eine warme Antwort verbirgt einen kaputten Upstream. Wiederholen Sie über TCP, dann wiederholen Sie mit abgeschaltetem Tunnel, um zu sehen, was der Resolver tut, wenn sein bevorzugter Pfad weg ist. Dieses letzte Verhalten entscheidet, ob das Design fail-closed oder nur glücklich ist.