VPN-DNS funktioniert, aber .local-Namen scheitern weiterhin: Wer löst sie auf?

Zwei Rechner im selben VPN, derselbe Hostname, und nur einer von ihnen löst ihn auf: Der Unterschied ist meist nicht der Tunnel, sondern welcher Resolver geantwortet hat. Auf einem Linux-Desktop kann dieser Name über den Name Service Switch, über den Stub von systemd-resolved oder über einen Resolver laufen, den die Anwendung mitgebracht hat, und jeder davon wendet seine eigene Regel auf dasselbe Suffix an. Am Suffix gehen die Regeln auseinander, weil .local keine neutrale Bezeichnung ist. Finden Sie heraus, welchen Pfad das fehlerhafte Programm tatsächlich nimmt, bevor Sie die Reihenfolge ändern, in der etwas läuft.

Zwei Resolver, zwei verschiedene Antworten

Eine klassische glibc-Suche geht die hosts:-Zeile in nsswitch.conf durch und fragt jedes Modul der Reihe nach, bis eines antwortet. Ein Client, der über den Stub-Listener mit systemd-resolved spricht, fragt stattdessen einen einzigen Prozess, und dieser Prozess wendet Richtlinien pro Verbindung plus seine eigenen Sonderfälle an. Eine Anwendung, die ihren eigenen Resolver mitbringt oder eine Bibliothek einbindet, die das tut, kann beide umgehen. Ein Hostname kann daher drei Eigentümer auf einem Rechner haben, und nur einer davon weiß, was das VPN beabsichtigt hat.

Bestimmen Sie den Eigentümer, bevor Sie etwas ändern, denn die Lösung ist für jeden der drei anders. Ein Browser und ein Kommandozeilenwerkzeug auf demselben Desktop dürfen sich zu Recht uneinig sein, und diese Uneinigkeit ist der Hinweis, nicht der Fehler. Wenn der Browser den Namen auflöst und das Werkzeug nicht, debuggen Sie einen Resolver-Pfad und keine VPN-Route. Bestätigen Sie die Route separat, damit ein Routingfehler nicht mit einem Namensdienstfehler verwechselt wird. Wenn beide übereinstimmen, liegt der Fehler oberhalb des Hosts, und die Resolver-Konfiguration hier ist keine weitere Änderung wert.

Welcher Befehl Ihren Resolver tatsächlich gefragt hat

Zwei reine Lesebefehle beantworten verwandte Fragen, und ihr Vergleich lokalisiert das Problem schneller als das Lesen der Konfiguration. Verwenden Sie einen echten internen Namen und halten Sie die Ausgabe privat, denn interne Einträge bleiben intern. Führen Sie beide in derselben Sitzung aus, in der das fehlerhafte Programm läuft:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Der erste fragt über die konfigurierten Module, was ein typisches Programm erlebt. Der zweite fragt systemd-resolved direkt und meldet die Verbindung, das Protokoll und den Server, der geantwortet hat. Eine Abfrage des Unternehmensservers per Adresse beweist nur, dass der Server den Eintrag hält, denn sie sagt nichts darüber, ob die Anwendung ihn jemals gefragt hat. Lesen Sie die Verbindung, die das VPN trägt, und die Domains, die sie beansprucht, und vergleichen Sie dann diese Liste mit dem Suffix im fehlerhaften Namen.

Warum .local Ihre Unicast-Zone überspringt

die Referenz von systemd-resolved führt aus, dass mehrteilige Namen, die auf .local enden, bei aktiviertem mDNS normalerweise an Multicast-DNS gehen und nicht an gewöhnliches Unicast-DNS. RFC 6762 hält diesen Namensraum für linklokales Multicast frei, sodass eine Unternehmenszone einen korrekten Eintrag halten kann, der für dieses Suffix nie befragt wird. Der Tunnel kann den Resolver einwandfrei routen und das Rennen trotzdem verlieren. Ein erfolgreicher Ping aus einem Cache sagt nichts über die Suche aus, die gerade stattgefunden hat.

Es gibt eine dokumentierte Ausnahme, und sie entscheidet die meisten dieser Fälle: Wenn eine Verbindung dieses Suffix als Suchdomain oder Routing-Domain deklariert, hält der Daemon es auf dem Unicast-Pfad und überspringt den Multicast-Sonderfall. Das ist eine Richtlinie pro Verbindung und keine globale Präferenz. Zwei Rechner mit demselben VPN-Server können sich unterschiedlich verhalten, wenn ein Netzwerkprofil die Domain deklariert und das andere nicht, lesen Sie also das aktive Profil und nicht das, von dem Sie glauben, es bearbeitet zu haben.

Die enge Ausnahme schlägt eine globale Umsortierung

Für eine bestehende Zone, die Sie nicht umbenennen können, sollen die Resolver- und VPN-Verantwortlichen die Domain auf der Verbindung deklarieren, die sie trägt. Ein Routing-Domain-Eintrag für dieses eine Suffix plus die vorgesehene Serveradresse ist eine kleine Änderung mit einem benannten Verantwortlichen, und sie lebt bei der Verbindung statt in einer handbearbeiteten Datei.

Sie übersteht auch eine Trennung, weil die Verbindungsrichtlinie erneut angewendet wird, wenn die Verbindung zurückkehrt. Die gemeinsame nsswitch.conf zu bearbeiten ist die verlockende und die teurere Alternative, denn sie ändert das Suchverhalten für jeden Namen auf dem Rechner, die lokale Erkennung eingeschlossen. Den Multicast-Daemon zu deaktivieren ist ebenso wenig gleichwertig: Es entfernt das lokale Verhalten, ohne irgendeinem Resolver die Unternehmenszone beizubringen. Wenn der Dienst neu statt geerbt ist, legen Sie ihn unter eine Subdomain, die Ihre Organisation kontrolliert, und überspringen Sie den Wettbewerb vollständig. Wählen Sie die enge Ausnahme, wenn der Name in der Firmware festgeschrieben oder auf ein Etikett gedruckt ist, und wählen Sie eine neue Subdomain, wenn Sie den Client noch kontrollieren.

Was nach der Änderung zu beweisen ist

Beweisen Sie die Korrektur mit der eigenen Suche der Anwendung statt mit einem Werkzeug, das Sie zum Testen installiert haben, und leeren Sie jeden Cache, der für sie antworten könnte. Bestätigen Sie dann den Resolver-Pfad und die Verbindung, die die Antwort geliefert hat. Prüfen Sie schließlich, ob sich die lokale Erkennung noch wie vor der Änderung verhält, denn der Drucker, der verschwindet, ist der Teil, den die Leute zuletzt bemerken. Diese drei Befehle prüfen den Namen, den Pfad und die TLS-Identität in dieser Reihenfolge:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Eine korrekte Adresse mit dem falschen Zertifikat lässt einen strengen Client immer noch scheitern, prüfen Sie also den Namen, den die Anwendung erwartet, sobald die Auflösung funktioniert. Bestätigen Sie, dass der Dienst Verbindungen von der VPN-Adresse annimmt und nicht nur aus dem Bürobereich. Schreiben Sie den Domain-Umfang, den Server und den Verantwortlichen in die Dokumentation der Verbindung. Sonst greift die nächste Person, die auf diesen Fehler stößt, nach derselben globalen Änderung, die Sie gerade vermieden haben.