WireGuard-DNS auf dem iPhone: Die Domain ist nur ein Suchsuffix

Sie schreiben eine Zeile mit einer Resolver-Adresse und einer Firmendomain und erwarten, dass nur Namen in dieser Domain den Tunnel-Resolver verwenden. Auf dem Apple-Client gehen jetzt alle Namen dorthin, und auch kurze Namen in der Domain werden aufgelöst. Die Zeile tut zwei getrennte Dinge, und nur eines davon betrifft die Frage, welche Anfragen der Tunnel bearbeitet. Das andere ist eine Tipphilfe, die durch Wunschdenken zur Richtlinie befördert wurde.

Wozu die DNS-Zeile zerlegt wird

Der Client liest den Eintrag als Liste und ordnet jedes Element nach seiner Form ein. Alles, was wie eine Adresse aussieht, wird zum DNS-Server; alles, was wie eine Domain aussieht, wird zum Suchsuffix. Beides landet in den Tunneleinstellungen, aber in verschiedenen Feldern. Eine beispielhafte Zeile für einen Tunnel mit einem privaten Resolver und einer internen Domain sieht so aus.

DNS = 10.24.8.53, lab.internal.example

Die Adresse liefert den Resolver. Die Domain liefert ein Suffix, mit dem ein Client einen kurzen Namen tippen kann und das System den Rest ergänzt, bevor es fragt. Keines der beiden Elemente sagt etwas darüber, den Resolver auf diese Domain zu beschränken, und genau das erwarten die Leute und bekommen es nicht. Nur ein Feld auf der Plattform kann diese Einschränkung ausdrücken, und es ist nicht dieses.

Zwei Apple-Felder, zwei verschiedene Aufgaben

Apple legt den Unterschied in seinem DNS-Einstellungsobjekt offen. Die Suchdomain-Liste ist dokumentiert als die Liste, mit der einteilige Hostnamen qualifiziert werden: Tippen Sie einen nackten Hostnamen, und das System kann jedes Suffix der Reihe nach anhängen. Das ist eine Vervollständigungsregel, keine Routingregel. Nichts in dieser Liste entscheidet, welcher Server gefragt wird.

Die Match-Domain-Liste ist eine andere Eigenschaft. Sie entscheidet, welche Namensräume diese DNS-Einstellungen verwenden, und ein leerer Eintrag bedeutet die Standarddomain statt eines bestimmten Suffixes. Generator für Paket-Tunneleinstellungen im Apple-Client folgt diesem Modell. Er legt geparste Suchsuffixe in die Suchliste und setzt, wenn Server vorhanden sind, die Match-Liste auf die leere Zeichenkette. Das Ergebnis ist ein Tunnel-Resolver, der alles beantwortet, was das System ihm schickt, plus ein Suffix, das bei kurzen Namen hilft.

Eine Domain in dieser Zeile ist also kein Namensraum-Selektor. Eine weitere hinzuzufügen verengt nicht, welche Anfragen der Tunnel nutzt, und sie zu entfernen erweitert sie auch nicht. Das Einzige, was sich ändert, ist, wie viele kurze Namen vervollständigt werden.

Warum jeder Name trotzdem den Tunnel-Resolver erreicht

Mit dem leeren Match-Eintrag ist der Tunnel ein Kandidaten-Resolver für gewöhnliche Namen, nicht nur für die Firmendomain. Bei einer Full-Tunnel-Konfiguration spielt das meist kaum eine Rolle, weil der gesamte Verkehr ohnehin im Tunnel ist. Bei einem Split-Tunnel spielt es eine große Rolle. Öffentliche Namen können jetzt von einem Resolver aufgelöst werden, der nur eine private Zone hält, und ein Fehler sieht wie ein kaputtes VPN aus, obwohl es eigentlich ein Resolver ist, der nur einen Teil des Namensraums beantwortet. Der Tunnel ist in Ordnung, die Anfragen verlassen ihn, und die Antworten kommen leer zurück.

Es gibt zwei Reparaturen, und es sind unterschiedliche Entscheidungen. Machen Sie den Tunnel-Resolver zu einem vollständigen Resolver, der öffentliche Namen über den genehmigten Weg weiterleitet, oder hören Sie auf, öffentliche Namen dorthin zu schicken, indem Sie die Client-Konfiguration statt der Domainliste ändern. Die erste hält jede Anfrage im Tunnel und vertraut dem Upstream. Die zweite hält einige Anfragen lokal und akzeptiert, dass private Namen aufhören können zu funktionieren, während der Tunnel aus ist.

Was Split-DNS tatsächlich bräuchte

Eine namensraumbeschränkte Resolver-Richtlinie erfordert einen Client, der es Ihnen erlaubt, sie auszudrücken: Domains auf Apple-Plattformen matchen, oder eine gleichwertige Einstellung in dem Produkt, das Sie verwenden. Ein Konfigurationsfeld, das nur Server und Suffixe akzeptiert, kann sie nicht ausdrücken, egal wie es gesetzt wird. Ein Profil kann die Richtlinie tragen, weil es eine verwaltete Konfiguration beschreibt und keinen Hinweis zur Verbindungszeit. Es kann die Domain, die Server und das benennen, was passieren soll, wenn diese Domain nicht erreichbar ist. Das ist der Unterschied zwischen einer Einstellung und einem Vertrag.

Auf verwalteten Apple-Geräten wird das normalerweise über ein Konfigurationsprofil ausgeliefert, das die domainspezifischen DNS-Einstellungen trägt. Das ist ein anderer Mechanismus als eine WireGuard-Konfigurationsdatei, und beide können nur koexistieren, wenn der Client das Profil respektiert. Prüfen Sie, wie Ihr Client das Feld tatsächlich nennt, bevor Sie annehmen, dass sich beide Produkte gleich verhalten. Das Tool wg-quick auf einem Mac und die WireGuard-App auf einem iPhone lesen ähnliche Zeilen und installieren sie über verschiedene Schichten.

Lesen Sie die installierten Einstellungen, nicht die Konfiguration

Auf einem Mac können Sie prüfen, womit das System am Ende gelandet ist, was aufschlussreicher ist, als die Datei, die Sie geschrieben haben, erneut zu lesen. Die Resolver-Liste zeigt, welche Server für welche Domains konfiguriert sind, und die bereichsbezogenen Abfragen zeigen, welcher gewonnen hat. Ein Client, der die Zeile verpfuscht, zeigt das hier statt in der Datei, die Sie geschrieben haben. Auf iOS gibt es keine entsprechende Kommandozeile, also ist der Beweis dort ein Ergebnis: ein privater Name, der über den Tunnel aufgelöst wird, und ein öffentlicher Name, dessen Antwort verrät, welcher Resolver geantwortet hat.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Diese beiden Befehle geben die aktuelle Resolver-Konfiguration und die DNS-Server für den aktiven Dienst aus. Wenn der Tunnel-Resolver als Standard-Resolver ohne Domain-Beschränkung erscheint, tut die Konfiguration genau das, worum der Client gebeten hat. Beheben Sie das, indem Sie den Mechanismus ändern, nicht indem Sie ein zweites Suffix hinzufügen und hoffen, dass sich das Verhalten ändert.