Interne Namen scheitern am VPN, während öffentliche Seiten auflösen

Ein Nutzer meldet, dass der Intranet-Hostname über das VPN nicht aufgelöst wird. Ein zweiter Bericht vom selben Laptop besagt, dass ein Leak-Test weiterhin Abfragen zeigt, die der lokale Resolver beantwortet. Sie klingen wie ein Problem und sind zwei, mit unterschiedlichen Belegen, und die übliche Reparatur für das erste verschlimmert das zweite. Trennen Sie sie, bevor Sie eine Einstellung anfassen.

Zwei Symptome, die kein einzelner Fehler sind

Ein interner Name, der sich nicht auflösen lässt, bedeutet, dass die Frage irgendwohin ging, wo es keine Antwort darauf gibt. Abfragen, die den Tunnel verlassen, bedeuten, dass die Frage am falschen Ort ankam, selbst wenn die Antwort verfügbar war. Das sind entgegengesetzte Fehler: der eine ist eine fehlende Antwort, der andere ein überflüssiges Ziel.

Die Falle ist, dass der Büro-Resolver überall eingetragen den ersten Fehler behebt und den zweiten garantiert. Ein öffentlicher Resolver überall macht das Gegenteil.

Notieren Sie beide Beobachtungen mit Zeitstempel und arbeiten Sie dann die vier Prüfungen unten der Reihe nach ab.

Welcher Resolver des Adapters die Frage bekommt

Unter Windows wählt der DNS-Client Server nach der Bindungsreihenfolge der Adapter, und der Tunneladapter ist nicht automatisch der erste. Öffnen Sie die erweiterten Einstellungen des Adapters und schieben Sie die Fernzugriffsverbindung über den physischen Adapter, dann verbinden Sie neu, damit die Änderung in einer frischen Sitzung gilt.

Die Bindungsreihenfolge ist nur die erste Hälfte. Der Client muss auch wissen, welche Namen zu diesem Adapter gehören, und das ist eine Suffixfrage, keine Reihenfolgefrage.

Legen Sie die Ausgabe von ipconfig /all des funktionierenden Rechners neben die des Laptops, beide bei aufgebautem Tunnel erstellt. Der funktionierende Rechner zeigt ein verbindungsspezifisches DNS-Suffix an seinem Büroadapter, und der Laptop zeigt am Tunnel womöglich keines. Dieser Unterschied erklärt eine ganze Klasse von Meldungen der Art der Server ist doch da und der Name scheitert trotzdem, denn ohne Suffix wird der Kurzname nie in die Zone vervollständigt, die der Büro-Resolver bedient.

Ein Kurzname braucht ein Suffix, bevor er eine Route braucht

Einen unqualifizierten Hostnamen zu tippen bittet den Resolver, eine Domäne zu raten. Der Rat kommt aus der an die Verbindung gehängten Suffixliste, und ist diese Liste leer, geht die Abfrage als einzelnes Label hinaus, auf das keine private Zone passt.

Kopieren Sie das Suffix des funktionierenden Rechners in die IPv4-Eigenschaften des VPN-Adapters auf der DNS-Registerkarte und verbinden Sie neu. Unter Linux ist das Gegenstück die Suchdomäne am Tunnellink, die systemd-resolved pro Link und nicht global offenlegt.

Halten Sie die beiden Einstellungen in Ihren Notizen getrennt. Das Suffix ändert, was gefragt wird; die Resolver-Adresse ändert, wer gefragt wird. Eines zu reparieren, während das andere falsch ist, liefert ein Ergebnis, das zufällig wirkt.

Fragen Sie den Resolver direkt, dann den Namen

Eine direkte Abfrage an den Büro-Resolver trennt ein Namensproblem von einem Wegproblem, weil sie die Resolver-Auswahl des Clients vollständig umgeht.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Der erste Befehl fragt einen bestimmten Server nach einem voll qualifizierten Namen. Antwortet er, sind Resolver und Weg dorthin in Ordnung und der Fehler liegt bei der Auswahl oder beim Suffix. Läuft die Zeit ab, ist die Adresse falsch oder unerreichbar und das Problem liegt im Routing, nicht im DNS. Der zweite Befehl zeigt, was mit dem Kurznamen passiert, und der dritte gibt die Resolver-Konfiguration pro Link auf einem systemd-Host aus.

Achten Sie auf Wildcard-Antworten, die manche Netze für unbekannte Namen zurückgeben. Eine plausible Antwort beweist nicht, dass der gemeinte Server geantwortet hat, vergleichen Sie also die zurückgegebene Adresse mit der, die der interne Dienst tatsächlich nutzt. Gehört die Adresse zu einer Parkseite oder einem Proxy, hat der Resolver geantwortet, aber die Antwort war nie Ihre. Dieser Unterschied spart eine Stunde Jagd auf einen Tunnel, der die ganze Zeit funktionierte.

Unter Linux ersetzt ein VPN-Client, der /etc/resolv.conf umschreibt, die lokalen Resolver vollständig. vpnc legt DNSUpdate no offen, um das zu verhindern, und systemd-resolved kann nur die gelisteten Domänen an den Tunnellink routen. Beide Ansätze halten öffentliche Namen beim lokalen Resolver und schicken interne Namen ins Büro.

Leaks sind eine Regel, kein Häkchen

Namensauflösung ist ein UDP-Austausch an Port 53, ein Tunnel, der Webverkehr, aber kein UDP trägt, lässt die Abfrage also auf dem physischen Weg. Beweisen Sie es, indem Sie an der physischen Netzwerkkarte mitschneiden, während ein öffentlicher Name aufgelöst wird. Eine Abfrage, die auf dieser Schnittstelle lesbar sichtbar ist, bedeutet, dass der Tunnel sie nicht trägt.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Erscheint die Abfrage auf dieser Schnittstelle lesbar, trägt der Tunnel sie nicht. Die Reparatur ist eine Regel, die Port 53 nur zum vom VPN geschobenen Resolver erlaubt und andere Ziele verwirft, plus eine Client-Konfiguration, die die geschobene Option nicht still verwirft.

Der letzte Teil ist wichtiger, als er aussieht. Starten Sie OpenVPN mit route-nopull, und die geschobene DNS-Option verschwindet zusammen mit den Routen, es sei denn, der Pull-Filter wird erweitert, um sie zu behalten. Und ein Client, der dhcp-option DNS ignoriert, nutzt weiter, was er vorher hatte. Jede Änderung auf der Serverseite braucht eine frische Sitzung, denn die Resolver-Liste wird beim Aufbau des Tunnels geliefert, und eine veraltete Sitzung zeigt weiter den alten Stand.

Notieren Sie, welchen Fehler Sie tatsächlich beobachtet haben, bevor Sie das Ticket schließen. Eine fehlende interne Antwort und eine aus dem Tunnel entweichende Abfrage verlangen verschiedene Reparaturen, und eine Suffixänderung, die die erste behebt, kann die zweite still verschlimmern. Wer das Ticket als Nächstes übernimmt, wird dem Etikett vertrauen, also machen Sie das Etikett genau.