VPN-DNS-Routing pro Verbindung aus resolvectl richtig lesen

Führen Sie resolvectl status aus, und Sie erhalten eine Wand von Blöcken pro Verbindung, jeder mit eigenen Servern und einer eigenen Domainzeile. Die Zeile, die das Routing entscheidet, ist die Domainliste, nicht die Adresse des Namensservers, denn der lokale Stub leitet jede Anfrage an die Verbindung weiter, die den Namen beansprucht. Lesen Sie diese Ansprüche, bevor Sie die Antwort lesen, fragen Sie dann den Namen ab und prüfen Sie, welche Verbindung ihn erzeugt hat. Eine falsche Antwort von der richtigen Verbindung ist ein anderes Problem als eine richtige Antwort von der falschen.

Was jeder Block pro Verbindung Ihnen sagt

Jeder Block listet die Server, die der Resolver für diese Schnittstelle verwendet, die Domainliste und ob die Verbindung die Standardroute ist. Die Domainliste ist eine Menge von Ansprüchen, und der Resolver wendet die längste Suffixübereinstimmung an: Eine Anfrage für host.corp.example wird von einer Verbindung mit corp.example vor einer beansprucht, die nur die Standardroute trägt. Zwei Verbindungen, die dasselbe Suffix beanspruchen, überlassen das Ergebnis Priorität und Reihenfolge, deshalb verdienen Duplikate zuerst Aufmerksamkeit. Die aktuelle Serverzeile zeigt, welcher der gelisteten Server in diesem Moment verwendet wird.

Eine Stub-Adresse wie 127.0.0.53 in /etc/resolv.conf sagt nur, dass der Stub vorn steht. Sie nennt nicht das Upstream, das geantwortet hat, deshalb bleibt eine Diagnose, die nur auf resolv.conf beruht, stecken.

Lesen Sie die drei Arten von Domaineinträgen richtig

Die Tilde ändert das Suchverhalten, nicht das Routing. Ein Eintrag ohne Tilde ist sowohl Routingdomain als auch Suchdomain, also werden Namen darunter an diese Verbindung gesendet und einteiligen Namen wird das Suffix angehängt. Ein Tilde-Eintrag routet dasselbe Suffix, hält es aber aus der Suchliste heraus. Deshalb ändert das Entfernen einer Tilde, welche bloßen Namen aufgelöst werden, und deshalb ist eine fehlende Tilde ein Suchproblem und kein Ausfall von Split-DNS.

Der Standardrouteneintrag beansprucht alles, was keine andere Verbindung abdeckt. Ein Full-Tunnel-Profil will ihn meist, ein Split-Profil meist nicht, weil öffentliche Namen dann zum privaten Resolver reisen und dort scheitern können. Lesen Sie die Tabelle gegen die Absicht des Profils, statt Flags zwischen Profilen zu kopieren. Wenn zwei Verbindungen dasselbe Suffix beanspruchen, klären Sie die Prioritätsfrage, bevor Sie irgendetwas anderes bearbeiten.

Fragen Sie einen Namen ab und sehen Sie, welche Verbindung geantwortet hat

Der Unterbefehl query gibt die Adresse, das Protokoll und die Verbindung oder den Bereich aus, die die Antwort erzeugt haben. Testen Sie einen Namen, den das private Suffix beanspruchen sollte, und einen gewöhnlichen öffentlichen Namen, und vergleichen Sie dann die gemeldeten Quellen. Antwortet der private Name über die Funkverbindung, fehlt der Anspruch oder der Tunnel ist unten; antwortet ein öffentlicher Name in einem Split-Profil über den Tunnel, ist die Standardroute zu weit. Diese beiden Fehler sehen im Browser gleich und in dieser Ausgabe entgegengesetzt aus.

resolvectl status
resolvectl query host.corp.example

Achten Sie auch auf das gemeldete Protokoll, denn eine zwischengespeicherte Antwort oder eine aus der Hostdatei kann eintreffen, ohne dass ein Upstream gefragt wurde. Eine Antwort aus dem Cache beweist, dass der Name irgendwann aufgelöst wurde, nicht dass die aktuelle Richtlinie ihn korrekt routet.

Halten Sie Namensrouting und Paketrouting getrennt

Eine Resolverentscheidung schafft keinen Pfad. Der gewählte Server braucht weiterhin eine Route zu seiner Adresse, und die zurückgegebene Adresse braucht weiterhin eine Route ins private Netz, sodass eine korrekte DNS-Richtlinie mit einer Verbindung koexistieren kann, die sich nie öffnet. Wenn ein Name aufgelöst wird und die Anwendung scheitert, prüfen Sie die Adresse und die Route, statt DNS erneut zu ändern. Namensauflösung und Erreichbarkeit sind zwei Fragen mit zwei verschiedenen Eigentümern.

Anwendungen können den Systemresolver vollständig umgehen, über eine eigene Einstellung für sicheres DNS oder einen mitgelieferten Resolver. Das resolvectl-Ergebnis beschreibt den Systempfad, und ein Browser, der es ignoriert, wird jedem Ihrer Tests widersprechen. Prüfen Sie diese Einstellung, bevor Sie schließen, dass die Richtlinie kaputt ist.

Notieren Sie die Adresse, zu der der Name aufgelöst wurde, neben der Verbindung. Ein korrekter Name, der auf die falsche Adresse zeigt, ist ein Datensatzproblem und kein Routingproblem.

Prüfen Sie erneut, nachdem sich die Verbindung geändert hat

Ein Wiederverbinden oder ein Funkwechsel baut den Verbindungszustand neu auf, und ein Netzwerkmanager kann seine Domains und Server über alles installieren, was von Hand gesetzt wurde. Fragen Sie danach dieselben zwei Namen ab und vergleichen Sie mit der aufgezeichneten Basislinie. Wenn eine manuelle Änderung verschwunden ist, gehört die Korrektur in das Verbindungsprofil und nicht in einen Shell-Befehl. Das Aufzeichnen vorher und nachher macht das sichtbar.

Teilen Sie nur die Namen und den Serverkontext, die der Bericht braucht, denn interne Suffixe offenbaren die Topologie. Die systemd-resolved-Dokumentation zum Domainrouting deckt die Längste-Übereinstimmung-Regel und das Tilde-Verhalten ab, und einmal lesen verhindert die meisten Tabellenfehler oben: Abfrage-Routing in systemd-resolved.