Warum private DNS-Namen auf VPN-Clients scheitern und wo Sie nachsehen

Sie öffnen im Hotelzimmer ein Notebook, starten den Client, tippen den Namen des internen Fileservers ein – und bekommen nichts zurück. Der Tunnel meldet Verbindung, und ein Ping an eine Adresse im selben Subnetz antwortet weiterhin, der Transport ist also in Ordnung. Nur der Name schlägt fehl, und diese Lücke verengt das Problem auf zwei Stellen: welchen Resolver der Client gefragt hat und ob die erhaltene Antwort durch den Tunnel zurückkommt. Lösen Sie das eine und lassen das andere aus, und der Fehler wandert einfach weiter.

Bevor Sie ein Profil ändern, prüfen Sie, was der Client mit dem Namen macht. Unter Linux zeigt resolvectl query files.corp.example, über welchen Link und welchen Resolver die Antwort entstanden ist. Unter Windows zeigt Resolve-DnsName files.corp.example, welcher Server geantwortet hat und welche Adresse er zurückgegeben hat.

Lesen Sie die Antwort, bevor Sie etwas ändern

Kommt der Name innerhalb weniger Millisekunden als NXDOMAIN zurück, hat die Anfrage Ihre Zone nie erreicht und irgendein öffentlicher oder Hotel-Resolver hat geantwortet. Kommt er erst nach einer langen Pause zurück, verwirft unterwegs etwas UDP-Port 53, und der Client ist schließlich ausgewichen. Kommt die richtige Adresse zurück, aber die Verbindung stockt weiterhin, ist die Auflösung in Ordnung, und Ihr Problem liegt im Routing oder beim Dienst selbst.

Diese Dreiteilung erspart eine Stunde Rätselraten. Sie sagt Ihnen außerdem, ob Sie das VPN überhaupt anfassen müssen: Ein Name, der zur richtigen privaten Adresse auflöst, hat den Resolver-Pfad bereits bewiesen, also liegt die restliche Arbeit auf dem Datenpfad.

Verteilen Sie den Resolver aus dem Tunnel heraus

Clients zerfallen in zwei Gruppen. Der einen Gruppe kann der Server beim Verbindungsaufbau einen Resolver vorgeben; die andere behält die Einstellung in einer lokalen Datei, die kein Gateway aus der Ferne ändern kann.

OpenVPN gehört zur ersten Gruppe. Auf dem Server laufen push "dhcp-option DNS 10.8.0.53" und push "dhcp-option DOMAIN corp.example" über den Steuerkanal, aber nur, wenn in der Client-Konfiguration pull noch aktiviert ist. Ein von Hand bearbeiteter Client mit pull-filter ignore "dhcp-option" sieht sie nie, und diese eine Zeile erklärt erstaunlich viele Fälle von „der Server schiebt es, aber mein Notebook sieht es nicht“.

WireGuard gehört zur zweiten Gruppe, denn das Protokoll kennt überhaupt keine Optionsaushandlung. Resolver und Suchdomäne stehen im eigenen [Interface]-Block des Clients, etwa als DNS = 10.8.0.53, corp.example. wg-quick setzt das über resolvconf oder systemd-resolved um, und unter Windows legt der offizielle Client NRPT-Regeln an, die nur bestehen, solange der Tunnel steht – Get-DnsClientNrptPolicy listet sie auf, womit Sie schnell sehen, ob der Client Ihre Datei je angewendet hat.

IPsec/IKEv2 liegt dazwischen. Das attr-Plugin von strongSwan kann einen DNS-Server aus einem Pool zurückgeben, und ein Windows-Client akzeptiert das normalerweise, aber ein Profil, das seinen eigenen Namensserver festnagelt, gewinnt gegen alles, was das Gateway anbietet. Auf einem Linux-Client sind die entsprechenden manuellen Schritte resolvectl dns wg0 10.8.0.53 gefolgt von resolvectl domain wg0 '~corp.example'; beides verschwindet mit der Schnittstelle, was für eine tunnelspezifische Einstellung genau richtig ist.

Beschränken Sie das Suffix, statt jede Anfrage zu verschlucken

Die gesamte Resolver-Liste des Clients auf den internen Server zu zeigen ist einfach und meist falsch. Dann löst jeder öffentliche Name über den Ausgang Ihres Rechenzentrums auf, CDNs liefern entfernte Adressen zurück, und ein Ausfall des Resolvers reißt das Surfen des Nutzers mit.

Schicken Sie nur das private Suffix nach innen. Bei systemd-resolved ist eine Domäne, die mit ~ beginnt, reines Routing, also bedeutet ~corp.example, dass Anfragen unter diesem Suffix an die Server dieses Links gehen, während alles andere weiter das physische Netz nutzt. Windows erledigt dasselbe mit NRPT-Regeln, die auf einen Namensraum begrenzt sind, und macOS mit einer ergänzenden Resolver-Datei unter /etc/resolver/.

Multicast-Namen verdienen eine eigene Antwort. .local-Namen sind von der Konstruktion her link-local (RFC 6762), und eine Punkt-zu-Punkt-tun-Schnittstelle trägt diese Multicast-Gruppe nicht, also veröffentlicht ein zusätzlicher öffentlicher Resolver sie nicht, und fragt man einen internen Unicast-Resolver danach, kommt NXDOMAIN zurück. Ein Reflector wie avahi im Reflector-Modus kann zwei Segmente verbinden, aber das ist eine Entscheidung auf der Serverseite, die kein Client verlangen kann. Wenn ein Drucker oder NAS über den Namen erreichbar sein muss, geben Sie ihm stattdessen einen A-Record in Ihrer Zone.

Beweisen Sie, dass die Antwort zurückkommt

Eine richtige Antwort, die auf eine unerreichbare Adresse zeigt, sieht genau wie ein Resolver-Problem aus, bis Sie die Route prüfen. Fragen Sie den Kernel, wohin die Antwort gehen würde: ip route get 10.20.5.20 nennt die Schnittstelle und, nützlicher, die Quelladresse, die sie verwenden würde.

Achten Sie auf die Resolver-Adresse selbst. Ein Client mit DNS = 10.8.0.53 neben AllowedIPs = 10.20.0.0/16 schickt seine Anfragen über die physische NIC hinaus, wo sie still verpuffen, weil der Resolver in keinem Präfix liegt, das der Tunnel beansprucht. Diese Diskrepanz ist der häufigste Einzelgrund für Fehler in diesem ganzen Bereich, und sie bleibt unsichtbar, solange Sie die DNS-Einstellung nicht Zeile für Zeile mit den erlaubten Präfixen vergleichen.

Überlappende Bereiche verursachen den umgekehrten Fehler. Die Antwort ist richtig, die Route existiert, und sie zeigt auf den falschen Host, weil 192.168.0.0/24 zu Hause spezifischer ist als die Route des Tunnels in denselben Bereich. Nummerieren Sie eine Seite neu oder schieben Sie eine engere Route, dann prüfen Sie Firewall und Rückweg des Dienst-Hosts; die Hinweise von strongSwan zur Weiterleitung decken die sysctl-Seite dieses Wegs ab.

Zertifikate sind eine eigene Identitätsprüfung, die Leute gern dem DNS anlasten. Meldet der Browser eine Namensabweichung statt eines Auflösungsfehlers, hat die Namensauflösung bereits funktioniert, und dann ist die SAN im Zertifikat das, was repariert werden muss. Testen Sie HTTPS gegen den Namen, nie gegen die nackte IP.

Testen Sie erneut vom Client, nicht vom Gateway

Testen Sie in der Anwendung, über die sich der Nutzer beschwert, denn eine Namensauflösung auf der Kommandozeile beweist nicht, dass der Browser denselben Weg nimmt. Das sichere DNS von Chrome und network.trr.mode in Firefox können den System-Resolver völlig umgehen, und wenn sie das tun, scheitert ein privater Name oder sickert zu einem öffentlichen Resolver durch. Ein Vergleich von resolvectl query mit einem von Hand ausgeführten dig @10.8.0.53 files.corp.example sagt Ihnen, welcher der beiden Fälle eingetreten ist.

Trennen Sie dann die Verbindung und stellen Sie sie neu her, bevor Sie es als behoben bezeichnen. Einstellungen, die von Hand an einer Schnittstelle vorgenommen wurden, verschwinden mit der Schnittstelle, und ein Profil, das nur wegen einer übrig gebliebenen lokalen Änderung richtig aussah, versagt beim nächsten Start.

Eine kurze Checkliste für die nächste Maschine: Der Name löst über den Resolver des Tunnels auf, das Suffix ist begrenzt statt global, die Resolver-Adresse liegt innerhalb der erlaubten Präfixe, der Host aus der Antwort antwortet auf dem Dienst-Port, und das Zertifikat deckt den Namen ab, den der Nutzer eingegeben hat.