VPN-DNS übernimmt jede Auflösung: dns-priority in NetworkManager korrigieren

Verbinden Sie das Büro-VPN, und plötzlich geht jede Namensauflösung an den Unternehmens-Resolver. Öffentliche Namen werden weiterhin aufgelöst, also wirkt nichts kaputt, bis ein lokaler Druckername scheitert oder ein Split-Horizon-Eintrag die Büroadresse zurückgibt. Bei manchen Fedora-Installationen passiert das Gegenteil: Der Resolver des Providers antwortet weiter, nachdem der Tunnel steht. Beides ist eine Frage — welcher Resolver diese Anfrage besitzt — und auf NetworkManager-Systemen liegt die Antwort in den DNS-Eigenschaften der einzelnen Verbindung.

Zwei Verbindungen, ein gewinnender Resolver

Jede Verbindung gibt eine DNS-Priorität an. Normale Verbindungen stehen standardmäßig auf 50 und VPN-Verbindungen auf 0, und der niedrigere Wert gewinnt. Genau dieser Standard ist der Grund, warum eine VPN-Verbindung die kabelgebundene Strecke für jede beanspruchte Domain still übertrumpft: Null schlägt fünfzig, ohne dass es jemand gewählt hat.

Die Priorität ordnet die Kandidaten. Sie begrenzt nicht, wonach der Gewinner gefragt wird. Eine VPN-Verbindung ohne Suchdomain beansprucht alles, wer sie also bevorzugt, schickt auch öffentliche Anfragen in den Tunnel und bei einem Split-Tunnel-Design dorthin, wohin der Unternehmens-Resolver weiterleitet.

Die Priorität bestimmt die Reihenfolge, die Suchliste den Besitz

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Die Suchliste ist die Besitzanzeige. Eine nackte Domain wie corp.example wird zum Suchsuffix und zur Routing-Domain. Die reine Routing-Form ~corp.example schickt Suchanfragen unter diesem Suffix an diese Verbindung, ohne die Domain an kurze Namen anzuhängen. Diese Tilde ist der Unterschied zwischen „frag diesen Server“ und „frag diesen Server und beende mein Tippen“.

Nutzen Sie beide Formen, wenn Anwender kurze Hostnamen tippen und die Einträge auch über vollqualifizierte Namen adressiert werden. Nutzen Sie nur die Routing-Form, wenn Sie die Aufteilung wollen, ohne zu ändern, wie der Resolver einen nackten Namen vervollständigt.

Machen Sie die Bevorzugung dann ausdrücklich und aktivieren Sie neu:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Eine negative Priorität ist der dokumentierte Weg zu sagen „bevorzuge diese Verbindung“, und beide Adressfamilien zu setzen hält das Verhalten auf einem Host mit IPv6-Konnektivität gleichmäßig. Die Eigenschaft zu ändern, ohne die Verbindung neu zu aktivieren, ändert nichts an dem, was gerade läuft, deshalb endet die Reihenfolge mit einem ausdrücklichen up.

Lassen Sie systemd-resolved die Aufteilung halten

Das Standard-dnsmasq-Plugin leitet Anfragen in einen lokalen Resolver, daher bleibt die Trennung pro Strecke grob. systemd-resolved legt die Aufteilung pro Strecke offen, und resolvectl query nennt die Strecke, die geantwortet hat.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Danach trägt die Unternehmensstrecke corp.example, und ein öffentlicher Resolver bedient den Rest. Wenn eine Anfrage auf der falschen Strecke landet, nennt der Befehl die Strecke, die sie beantwortet hat, und das zu wissen ist besser, als nur die Adresse zu kennen.

Passen Sie das DNS-Design zum Tunneltyp

Datenschutz-Designs, die alles durch den Tunnel schicken, sollten keine Aufteilungsliste tragen, weil sie öffentliche Namen an den lokalen Resolver zurückgeben und die Absicht aufheben würde. Split-Tunnel-Designs brauchen eine: ohne sie sieht der Unternehmens-Resolver jede öffentliche Anfrage, und das Setup bricht in dem Moment, in dem der Tunnel fällt.

Dann gibt es den Kill Switch, der DNS außerhalb des Tunnels blockiert. Namen werden für die Zonen des Tunnels aufgelöst und scheitern überall sonst, während die Verbindung völlig gesund ist. Tragfähige Antworten sind eine ausdrückliche Erlaubnis für den LAN-Resolver oder ein lokaler Cache, der nur die Unternehmenszone weiterleitet, und beides ist eine Ausnahme mit Eigentümer statt eines Defekts im Tunnel.

Ein Profil, das die Resolver-Konfiguration beim Start der Schnittstelle neu schreibt, verhält sich ähnlich: Sobald der lokale Resolver unerreichbar ist, werden nur die Namen aufgelöst, die der Tunnel kennt. Welcher Mechanismus auch gilt, schreiben Sie auf, welche Namen in welchem Zustand funktionieren sollen, und geben Sie diese Liste an die Stelle, die die Meldungen bearbeitet.

Pro Strecke prüfen, und nach dem Neuverbinden noch einmal

Fragen Sie einen internen und einen öffentlichen Namen ab und beobachten Sie, wohin die Anfrage wirklich geht. Eine Leak-Check-Seite sagt Ihnen, welcher Resolver geantwortet hat, nicht welche Strecke das System gewählt hat, sie sagt also nichts über die Reihenfolge, die Sie gerade konfiguriert haben.

Führen Sie die beiden Abfragen nach einem Trennen und Neuverbinden erneut aus. Prioritäten werden beim Aktivieren einer Verbindung erneut angewendet, und ein alter symbolischer Link kann ein Upgrade überleben, an das sich niemand erinnert. Was am Ende festgehalten werden soll, ist, welcher Resolver welches Suffix besitzt, plus eine Prüfung, die morgen noch gilt.