Welcher Link antwortet: Routing-Domains für Split-Tunnel-VPN-DNS

Halten Sie normales Browsen auf dem lokalen Link, während Firmennamen über den DNS-Server aufgelöst werden, den der Tunnel bereitstellt. Wer die Standardroute der VPN abschaltet, bekommt die erste Hälfte und lässt die zweite ungebaut. Was folgt, sind die fehlende Einstellung, das Satzzeichen, das ihre Bedeutung ändert, und der eine Befehl, der zeigt, welcher Link tatsächlich geantwortet hat. NetworkManager und systemd-resolved werden durchweg vorausgesetzt, weil genau dieses Paar die Stelle ist, an der die Verwirrung meist beginnt.

Schritt eins: Route und Resolver trennen

ipv4.never-default beantwortet eine Routingfrage und hindert NetworkManager daran, diese Verbindung als Weg für den gesamten IPv4-Verkehr einzurichten. Eine DNS-Routing-Domain beantwortet eine andere Frage: Welche Nameserver welches Links erhalten eine Abfrage für ein passendes Suffix. Keines bedingt das andere, und ein Profil kann jahrelang das eine tragen, während das andere fehlt. Nur-Route bedeutet, dass der Tunnel die Firmensubnetze trägt und sein Resolver Firmennamen beantwortet, während alles andere unangetastet bleibt.

Setzen Sie nur die Routeneigenschaft, und interne Namen scheitern, meist mit einem Timeout, der wie ein defekter Tunnel klingt. Setzen Sie nur die Domain, und Sie haben stillschweigend jedem kurzen Namen auf der Maschine ein Suchsuffix hinzugefügt. Beide Fehler schicken das Ticket an den VPN-Server, der selten der Teil ist, der falsch ist.

Schritt zwei: eine reine Routing-Domain zum Profil hinzufügen

Angenommen, die Verbindung heißt corp-vpn, das Firmensuffix ist internal.example, und der Resolver des Tunnels ist bereits erreichbar. Lesen Sie zuerst die aktuellen Werte, denn die Befehle unten ändern Eigenschaften, die bereits Einträge enthalten können.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Ersetzen Sie Verbindungsnamen und Suffix durch Ihre eigenen, denn die Werte oben sind illustrativ. Das Pluszeichen ist wichtiger, als es aussieht: Damit wird der Wert an die bestehende Liste angehängt, ohne es wird die Eigenschaft ersetzt und unabhängige Domains verschwinden aus einem Profil, das gestern noch funktionierte. Die Tilde ändert das Verhalten, nicht den Stil, und der Absatz unten beschreibt, was sie auswählt. Behalten Sie das Lesen vor dem Schreiben bei, damit die Ersetzungsform Sie nie überrascht.

Eine führende Tilde kennzeichnet eine reine Routing-Domain, sodass passende Abfragen an die Server dieses Links gehen und das Suffix nicht an kurze Namen angehängt wird. Ohne die Tilde wird dieselbe Zeichenfolge auch zum Suchsuffix, ein anderes Ergebnis, das Leute selten beabsichtigen. Beide Einstellungen oben sind IPv4, ein Dual-Stack-Profil braucht also ipv6.never-default und dieselbe Routing-Domain in ipv6.dns-search, sonst nutzt die IPv6-Seite weiter die Standardroute, und interne Namen scheitern dort.

Schritt drei: resolvectl fragen, welcher Link geantwortet hat

Führen Sie resolvectl status aus und lesen Sie DNS-Server und Domains jedes Links, dann führen Sie resolvectl query host.internal.example gegen einen echten internen Namen aus, den Sie abfragen dürfen. Der zweite Befehl ist der einzige direkte Beweis, dass die Routing-Domain ihre Aufgabe erfüllt, denn er nennt den Link, der geantwortet hat. Eine Statusauflistung allein belegt die Konfiguration; die Abfrage belegt die Auflösung.

systemd-resolved wählt die am besten passende Routing-Domain, sodass eine spezifischere Domain auf einem anderen Link das Rennen trotzdem gewinnen kann. Kommt die Abfrage von einem Link, den Sie nicht erwartet haben, lesen Sie die Domainlisten, bevor Sie den DNS-Server der VPN anfassen. Eine Root-Domain von ~. passt auf alles, und wenn sie bereits vorhanden ist, gewinnt Ihre spezifische Domain für ihre eigenen Namen trotzdem, während der Link weit mehr beantwortet, als Sie gefragt haben. Entfernen oder verengen Sie diesen Root-Eintrag, wenn die Absicht nur Firmennamen waren.

Führt der VPN-Link überhaupt keinen DNS-Server auf, hat der Client nie einen registriert. Eine Routing-Domain ohne Server dahinter scheitert anders als eine fehlende Domain, also reparieren Sie zuerst die Registrierung.

Schritt vier: wenn der Name auflöst, der Dienst aber nicht

Eine korrekte Antwort belegt nur, dass die Auflösung funktioniert hat, und die Anwendung braucht weiterhin eine Route zu der Adresse, die sie erhalten hat. Diese Route muss die gerade konfigurierte geteilte Standardroute überstehen, prüfen Sie sie, bevor Sie wieder DNS beschuldigen. Prüfen Sie dann die Erreichbarkeit auf dem Port des Dienstes, denn eine Dateifreigabe oder ein Verzeichnisdienst scheitert an Auflösung, Routing oder Authentifizierung und erzeugt in jedem Fall sehr ähnliche Meldungen. Halten Sie diese drei Schichten getrennt, wenn Sie das Ergebnis melden, sonst prüft die nächste Person DNS erneut, das bereits korrekt war.

Die Samba-Änderung, die neben dieser Frage kursiert, betrifft die Zugriffsschicht, nicht die DNS-Wahl. Sie auf einen Namensauflösungsfehler anzuwenden ist der Weg, wie ein kleines Problem ein zweites bekommt.

Schritt fünf: den Resolver nicht ersetzen, um eine fehlende Domain zu beheben

Ratschläge, die die Resolver-Datei überschreiben oder einen anderen Resolver-Manager installieren, lösen ein anderes Problem. Das sind Systemintegrationsänderungen mit eigenen Fehlermodi, und keine davon fügt eine Routing-Domain hinzu, die nie konfiguriert wurde. Stellen Sie fest, welche Komponente die Namensauflösung auf der Maschine besitzt, bevor Sie sie ersetzen, denn auf einem NetworkManager-Desktop mit systemd-resolved ist dieses Eigentum bereits definiert. Dagegen zu kämpfen ist der Weg, wie aus einem funktionierenden Setup etwas wird, das niemand reproduzieren kann.

Reihenfolge der Arbeit: Bestätigen Sie, dass der Tunnel einen Resolver liefert, fügen Sie die reine Routing-Domain hinzu, verbinden Sie sich über die Profilsteuerung neu, verifizieren Sie den antwortenden Link, und testen Sie dann den Dienst an seinem Port. Diese Reihenfolge hinterlässt ein Ergebnis, das Sie der nächsten Person ohne ein zweites Gespräch übergeben können.