Warum umgeht der eigene DNS des Routers den VPN-Tunnel?

Client-Abfragen folgen dem Tunnel, während die eigenen Abfragen des Routers über das WAN hinausgehen, und die Firewall-Regel, die das eine steuert, hat keine Wirkung auf das andere. Der Grund ist kein Fehler: Eine weitergeleitete Anfrage und eine Anfrage, die der Router selbst erzeugt, sind zwei getrennte Flüsse, und jeder wird gegen einen anderen Teil der Konfiguration geprüft. Nur die Client-Hälfte zu erfassen liefert eine sichere Antwort über einen Pfad, den die zweite Hälfte nie benutzt. Die Abhilfe besteht darin, den Resolver des Routers gezielt auszurichten und dann beide Pfade getrennt zu prüfen.

Zu welchem Fluss die Paketaufzeichnung tatsächlich gehört

Eine Abfrage umfasst zwei Austausche. Ein LAN-Client sendet eine Abfrage an den Resolver des Routers, und sie kommt als weitergeleiteter Verkehr auf der LAN-Schnittstelle an, sodass eine Policy-Route oder NAT-Regel, die für weitergeleitete Pakete geschrieben wurde, sie erfassen kann. Danach antwortet der Router aus dem Cache oder öffnet bei einem Fehlschlag seine eigene Abfrage an einen Upstream-Server.

Diese zweite Abfrage hat den Router als Quelle und als eigenes Ziel, und die Plattform wählt ihren Pfad aus einem anderen Konfigurationsblock. Beide Austausche tragen denselben Namen, und keiner ist eine Kopie des anderen. Eine auf der LAN-Seite erstellte Aufzeichnung beweist daher, wohin das Paket des Clients ging, und sagt nichts über das ausgehende Paket.

Die praktische Prüfung besteht darin, beide Seiten gleichzeitig zu beobachten. Listen Sie auf dem Router den Socket des Resolvers auf, fragen Sie ihn lokal ab und zeichnen Sie die WAN-Schnittstelle auf:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Zeigt die Socket-Liste einen Listener, der an die Loopback- oder LAN-Adresse gebunden ist, antwortet der Router lokal, statt an einen anderen Host weiterzuleiten. Die Aufzeichnung zeigt dann, ob die resultierende Upstream-Abfrage über die Tunnelschnittstelle oder über das WAN hinausgeht, und das ist die Antwort, die die Policy-Route nie gegeben hätte.

Warum die Policy-Route die zweite Abfrage nie sieht

Firewall-Regeln werden gegen eine Schnittstelle, eine Quelle, ein Ziel und einen Port geschrieben und für Pakete ausgewertet, die durch die Box laufen. Eine Abfrage, die der Router selbst erzeugt, läuft durch nichts hindurch, weil ein lokaler Prozess sie direkt an die Routing-Tabelle übergibt. Policy-Routing und NAT gelten daher nur für den weitergeleiteten Pfad, und genau deshalb kann ein Regelsatz vollständig aussehen und dennoch den DNS des Routers außerhalb des Tunnels lassen.

Die Unterscheidung überlebt jede Firmware-Überarbeitung, weil sie aus dem Paketpfad folgt und nicht aus einer Funktion. Alles, was die Box für sich selbst erzeugt, ob Resolver-Abfragen, Zeitsynchronisation, Update-Prüfungen oder Zugriff auf Paketspiegel, ist lokal entstanden und landet im selben blinden Fleck. Deshalb beweist ein Test vom Laptop aus nichts über den Router.

Wo ein pfSense-Resolver seinen eigenen Upstream-Pfad festlegt

pfSense macht die Trennung sichtbar. Client-Verkehr kann per Policy-Route durch ein VPN-Gateway laufen, während der eigene Verkehr der Firewall der ausgehenden Einstellung des Resolvers folgt statt den LAN-Regeln. In der Weboberfläche steht diese Einstellung unter Services > DNS Resolver > Outgoing Network Interfaces, und ihr Wert ist die Liste der Schnittstellen, die der Resolver für Upstream-Abfragen verwenden darf.

Dort die Tunnelschnittstelle zu nennen, und nur diese Schnittstelle, ist es, was die eigenen Abfragen des Routers dem Tunnel folgen lässt. Auf der Voreinstellung belassen, wählt der Resolver einen Ausgang aus der Routing-Tabelle, der auf einem Host mit zwei WAN-Anschlüssen oder einem VPN oft das WAN ist.

Andere Firmware legt dieselbe Entscheidung unter einem anderen Namen offen: eine an eine Quelladresse gebundene Upstream-Serverliste, einen Nur-Weiterleitungsmodus oder eine dokumentierte Routenpolitik. Die Einstellung, nach der Sie suchen müssen, ist immer die, die einen Ausgang oder eine Quelle für lokal erzeugte Abfragen wählt. Die Referenz zur Resolver-Konfiguration dokumentiert diese Option für pfSense und ist vor der Änderung lesenswert.

Wählen Sie das Ausfallverhalten vor der Einstellung

Beim Ausfall des Tunnels sind zwei Verhaltensweisen vertretbar: Upstream-Abfragen stoppen, damit nichts abfließt, oder auf einen genehmigten Resolver auf einem bekannten Pfad zurückfallen. Beides sind Richtlinien, und keine davon erhält man standardmäßig. Entscheiden Sie, welche das Netzwerk braucht, bevor Sie die Schnittstellenliste anfassen.

Das Schließen bei Ausfall ist leichter zu verteidigen, macht aber einen Tunnelausfall zu einem Namensauflösungsausfall für jedes Gerät hinter dem Router. Der Rückfall hält das Büro nutzbar, um den Preis eines Upstream-Austauschs außerhalb des Tunnels, der bewusst akzeptabel sein muss und nicht versehentlich. Schreiben Sie die Wahl auf, denn die nächste Person, die eine Resolver-Adresse außerhalb des VPN sieht, wird sie als Leck lesen, sofern keine Notiz etwas anderes sagt. Diese Notiz ist es, die einen dokumentierten Rückfall von einem unerklärten Befund in der Überprüfung des nächsten Quartals trennt.

Zwei Fälle erschweren die Entscheidung. Private Namen brauchen möglicherweise einen internen Resolver, den der Tunnel erreichen kann, und ein Browser oder eine Anwendung mit eigenem verschlüsseltem DNS kann den Router ganz umgehen, sodass der von Ihnen konfigurierte Resolver nicht immer der ist, den eine bestimmte App verwendet.

Testen Sie beide Pfade und halten Sie die Ergebnisse getrennt

Ein browserbasierter DNS-Test beantwortet eine enge Frage: Welche Resolver hat dieser Browser unter den Bedingungen dieses Tests verwendet. Er erfasst nicht die Geräte im Netzwerk und kann keine Abfrage sehen, die der Router für sich selbst erzeugt hat. Behandeln Sie seine Ausgabe als einen Datenpunkt und nicht als Prüfung.

Fragen Sie von einem LAN-Client aus den Router nach einem öffentlichen Namen und dann nach einem privaten, den nur Ihre interne Zone beantworten sollte. Ein Fehlschlag nur bei der zweiten Abfrage deutet auf Namensweiterleitung hin und nicht auf den Tunnel:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Bringen Sie dann den Tunnel zum Erliegen und wiederholen Sie beide Abfragen. Abgelehnte Antworten bedeuten, dass der Resolver bei Ausfall schließt; eine erfolgreiche Antwort deutet auf einen Rückfall-Resolver und den von ihm benutzten Pfad hin. Vergleichen Sie das mit der Notiz, die Sie geschrieben haben, und mit einer Aufzeichnung an der WAN-Schnittstelle aus derselben Minute.

Halten Sie die Beobachtungen im Protokoll getrennt: den Austausch zwischen Client und Router, den Austausch zwischen Router und Upstream und die Konfiguration, die den zweiten entschieden hat. Eine spätere Routing-Änderung wird diesen zweiten Austausch ohne Vorwarnung beanspruchen. Eine Antwort, die von einem anderen Ort als dem VPN-Endpunkt kommt, ist für sich genommen kein Leck; zum Leck wird sie erst, wenn die Konfiguration diesen Pfad versehentlich gewählt hat.