Ihre VPN-Domain in dnsmasq ist kein Zonentransfer

Sie suchen die Unternehmenszone in der dnsmasq-Konfiguration des Clients, finden sie nicht und schließen daraus, dass das VPN seine Domain nicht gepusht hat. Gepusht wurde ein Routing-Hinweis, keine Zone. Der Client zeichnet die Domain und den Resolver auf, der dafür antworten soll, und das verwaltete Backend macht daraus bedingte Weiterleitung. Am falschen Ort zu suchen erzeugt eine sichere und völlig falsche Diagnose.

Was der Client akzeptiert hat, ist nicht das, was das Gateway angeboten hat

Ein Gateway kann einen Resolver, eine Domain und die Route anbieten, die nötig ist, um diesen Resolver zu erreichen, und der Client kann alle drei oder keine davon akzeptieren. Ein importiertes Profil, ein Hilfsskript oder eine Richtlinie, die gepushte Optionen ignoriert, kann die akzeptierte Menge leer lassen, während die Serverseite korrekt aussieht. Beginnen Sie beim aufgezeichneten Zustand des Clients und nicht bei der Serverkonfiguration, denn dieser Zustand ist das, was der Resolver tatsächlich erhält. Fehlt die akzeptierte Domain, spielt alles Weitere keine Rolle mehr. Prüfen Sie die DNS-Eigenschaften der Verbindung, bevor Sie einen Cache untersuchen.

Diese Unterscheidung erklärt die meisten Berichte über eine Domain, die nie ankam. Sie wurde angeboten und nicht angewendet.

Zwei Arten von Domaineinträgen

Eine Verbindung kann gewöhnliche Suchdomains und reine Routendomainen tragen, und die zweite Art beginnt mit einer Tilde. Eine Suchdomain leitet Abfragen weiter und lässt kurze Namen expandieren, was auf einer Workstation praktisch und auf einem Server überraschend ist. Eine reine Routendomain besagt, dass Abfragen für dieses Suffix an bestimmte Server gehen sollen, ohne zu ändern, wie kurze Namen aufgelöst werden. Dieselbe Domain auf beide Arten zu schreiben ist keine Redundanz, weil die beiden Einträge unterschiedliche Aufgaben haben.

Für einen privaten Namensraum ist die reine Routenform meist die, die Sie wollen. Sie hält das Unternehmenssuffix auf den Unternehmensresolver gerichtet und lässt alles andere in Ruhe.

localhost in resolv.conf ist kein Fehler

Wenn ein lokaler Caching-Resolver verwendet wird, zeigt die Systemdatei auf die Loopback-Adresse und nichts sonst. Dieser Eintrag bezeichnet den lokalen Listener, nicht die vorgelagerten Server, die der Manager ihm übergeben hat. Die Unternehmensadresse fehlt in der Datei zu Recht.

Diesen Eintrag durch einen öffentlichen Resolver zu ersetzen ist die klassische Fehlkorrektur. Sie stellt die öffentliche Namensauflösung wieder her und verwirft die bedingte Richtlinie in derselben Änderung.

Verwechseln Sie die Backends nicht

Eine verwaltete dnsmasq-Instanz und ein Systemresolver sind verschiedene Programme mit unterschiedlicher Konfiguration und unterschiedlichen Statusansichten. Ein Statusbefehl für das eine sagt nichts Nützliches über das andere.

Stellen Sie fest, welches Backend der Manager verwenden soll, und lesen Sie dann die generierte Konfiguration dieses Backends statt einer distributionsweiten Datei, die zufällig existiert. Der Manager schreibt seine eigene Instanzkonfiguration und unterstützt benutzerdefinierte Optionen für diese Instanz, sodass das Bearbeiten einer unabhängigen globalen Datei nichts ändert und wie eine Änderung ohne Wirkung aussieht. Einen zweiten Daemon auf Port 53 zu starten ist schlimmer als nutzlos, denn jetzt sind sich zwei Programme uneinig darüber, wem der Port gehört. Klären Sie zuerst den Eigentümer und bearbeiten Sie dann die Stelle, an der dieser Eigentümer liest.

Testen Sie den Namensraum, nicht nur die Antwort

Fragen Sie einen erlaubten privaten Namen und einen öffentlichen Kontrollnamen über den normalen Pfad der Anwendung ab. Eine direkte Abfrage gegen den Unternehmensserver beweist, dass der Datensatz existiert; sie beweist nicht, dass der Client diesen Server ausgewählt hat. Die zweite Abfrage ist die, die die Richtlinie testet.

Wiederholen Sie das dann nach einer erneuten Verbindung und nach einer Trennung. Die Zuordnung sollte dem Lebenszyklus der Verbindung folgen, und die privaten Namen sollten aufhören zu antworten, wenn der Tunnel weg ist, statt auf einen öffentlichen Resolver zurückzufallen, der für dasselbe Suffix antwortet. Wenn sie doch zurückfallen, haben Sie ein Leck gefunden, das ein anderer Defekt ist als eine fehlgeschlagene Auflösung. Notieren Sie, welches Backend lief, welche Domains angewendet wurden und was jede Abfrage zurückgab.