Wie Domänenregeln von Apple VPN On Demand einen Tunnel auslösen

Der Tunnel öffnet sich, wenn Sie einen internen Namen anfordern, und bleibt geschlossen, wenn die nächste App ihn genauso dringend braucht. Das ist kein Fehler in der App, sondern die Form einer Domänenregel. Apples On-Demand-Konfiguration beschreibt Bedingungen für den Verbindungsaufbau, und die Domänenform dieser Bedingungen stellt dem System-Resolver eine Frage, bevor sich ein einziges Paket bewegt. Zwei Fragen werden ständig vermischt: wann der Tunnel hochkommen soll und was der Tunnel trägt, sobald er existiert. Das Erste ist ein Auslöser, das Zweite eine Routen- und Resolver-Richtlinie, und ein Profil setzt meist beides in derselben Payload, weshalb eine korrekte Domänenregel Sie trotzdem im falschen Netz lassen kann.

Auslöser und Verkehrsauswahl liegen auf verschiedenen Schichten

Eine On-Demand-Regel lebt im On-Demand-Wörterbuch einer VPN-Payload: eine geordnete Liste von Regeln, jede mit einer Aktion und einer Menge von Übereinstimmungsbedingungen. Das System wertet sie aus, wenn sich die Konnektivität ändert oder wenn etwas das Netz erreichen will, und die Aktion entscheidet, ob der Tunnel hochgefahren, ausgewertet, getrennt oder ignoriert wird. All das geschieht in der Netzwerkschicht der Plattform, bevor Ihre App einen Socket hat.

Was danach kommt, ist eine separate Gruppe von Schlüsseln: die IPv4- und IPv6-Einstellungen des Tunnels, seine eingeschlossenen und ausgeschlossenen Routen, seine DNS-Serveradressen und unter iOS und iPadOS die Zuordnung pro App, die entscheidet, welche Apps den Tunnel überhaupt nutzen dürfen. Ein Profil kann einen breiten Auslöser mit einer engen Route paaren oder einen engen Auslöser mit einer Standardroute. Lesen Sie nur die eine Hälfte, und die andere sieht wie eine Fehlfunktion aus.

Ich halte ein Laborprofil, das sich verbindet, wann immer etwas unter einer internen Domäne angefragt wird, aber nur ein /16 in den Tunnel routet. Es tut genau das, was seine Payload sagt, und es ist auch die Art Profil, die Tickets erzeugt: Leute nehmen an, ein verbundener Tunnel bedeute, ihr Verkehr sei darin.

Was eine Domänenregel den Resolver wirklich fragt

Die Domänenform der Regel, oft connect-if-needed genannt, untersucht keine Paket-Payloads und beobachtet keine URLs. Wenn ein Name aufgelöst wird, vergleicht das System ihn mit den Domänen in der Regel und fragt bei einer Übereinstimmung, ob dieser Name über die DNS-Server auflösbar ist, die der Tunnel bereitstellt. Antwortet der Resolver des Tunnels, gilt der Name als intern und die Verbindung wird gestartet. Antwortet stattdessen der lokale Resolver, gilt der Name als extern und es erscheint kein Tunnel. Apples Deployment-Übersicht beschreibt das als Netzerkennung, gefolgt von Verbindungsauswertung.

Daraus folgen zwei Konsequenzen. Das Profil muss DNS-Server innerhalb des Tunnels benennen; eine Domänenregel ohne Tunnel-Resolver hat nichts zu vergleichen, also kann die Auswertung nicht die erwartete Übereinstimmung liefern. Und die Abfrage muss den System-Resolver erreichen. Eine App oder ein Browser mit eigenem verschlüsselten DNS, eine Erweiterung, die lokal antwortet, oder eine Verbindung zu einer literalen Adresse erzeugt nie die Namensauflösung, auf die die Regel gewartet hat. Einer der längsten Nachmittage, die ich verbracht habe, endete, als ich feststellte, dass der Client vor dem Tunnel DNS over HTTPS verwendete.

Auch Caching entfernt den Auslöser. Ein bereits im Cache befindlicher Name kann ohne die Probe beantwortet werden, die den Tunnel gestartet hätte, sodass eine Regel, die gestern funktionierte, nach einem Neustart oder nachdem der Tunnel eine Weile oben war, versagt. Unter macOS setzt sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder den Zustand zurück; unter iOS liefert das Umschalten des Flugmodus oder ein Neustart des Geräts einen vergleichbaren sauberen Zustand.

Übereinstimmungsumfang: Namen, Apps und Netze

Domänenabgleich ist ein Typ unter mehreren. Eine Regel kann auch den Schnittstellentyp (Wi-Fi, Mobilfunk, Ethernet) und eine bestimmte SSID abgleichen, und Einträge pro App oder Safari-Domäne binden einen Tunnel an einen Arbeitsablauf. Diese Bindung erklärt die seltsame Erfahrung, dass nur eine App sich anders verhält als alles andere: Die anderen Apps liegen außerhalb des Tunnelumfangs und nutzen weiter den lokalen Pfad, selbst wenn das Tunnelsymbol verbunden meldet.

Die Reihenfolge ist wichtiger, als Leute erwarten. Regeln werden der Reihe nach ausgewertet, und die erste Übereinstimmung liefert die Aktion, also gewinnt eine breite Verbinden-bei-jedem-Wi-Fi-Regel über einer engen Domänenregel still und macht die Domänenregel untestbar. Bevor Sie die Domänenliste umschreiben, bestätigen Sie, dass keine frühere Regel bereits gepasst hat.

Deshalb ist Always-on auch nicht nur eine strengere On-Demand-Regel. Always-on-Durchsetzung ist ein separater Deployment-Modus mit eigenen Aufsichts- und Verwaltungsanforderungen; er hält einen Tunnel offen, statt auf einen Namen zu reagieren. Wenn Sie einen Tunnel brauchen, der nie abfällt, ist eine Domänenregel das falsche Werkzeug.

Fehlermodi, die eine kaputte Regel nachahmen

Die meisten Meldungen, eine Domänenregel funktioniere nicht, landen an einer von fünf Stellen, und nur die letzte davon ist der Regeltext.

Captive Portals verdienen eine eigene Zeile, weil Hotel- und Flughafen-Wi-Fi genau die Abfrage abfängt, von der die Regel abhängt. Bis das Portal das Gerät zulässt, ist der DNS-Server des Tunnels unerreichbar, die Probe scheitert, und der Fehler sieht wie eine falsch geschriebene Domäne aus. Authentifizierung ist der andere stille Fall: Die Regel kann auslösen, der Tunnel kann zu verbinden beginnen, und die Verbindung stirbt an einem abgelaufenen Zertifikat oder einer Eingabeaufforderung, die auf einem anderen Display erscheint.

IPv6 erzeugt eine Variante, die leicht falsch diagnostiziert wird. Ein Name mit beiden Adressfamilien kann zuerst aus einem AAAA-Record beantwortet werden, während die Routenliste des Tunnels nur IPv4 trägt. Ein Browser klappt, ein anderer scheitert, und die Domänenliste ist völlig unschuldig.

Testen Sie mit einer echten Anfrage, in dieser Reihenfolge

Lesen Sie die Richtlinie, bevor Sie raten. Unter macOS gibt sudo profiles show -type configuration installierte Profile einschließlich der VPN-Payload aus, scutil --nc list zeigt den Dienststatus, und scutil --nc show <service> gibt das On-Demand-Wörterbuch aus, das das System verwendet. Auf einem verwalteten iPhone oder iPad kommt dieselbe Payload aus der Verwaltungskonsole oder einem MDM-Bericht. Netzwerkprotokolle gibt es mit log stream --predicate 'subsystem == "com.apple.networkextension"' unter macOS und über die Gerätekonsole, wenn das Telefon angeschlossen ist.

Testen Sie dann mit einem Hostnamen, der in dieser Sitzung noch nicht abgefragt wurde. Wählen Sie einen Namen in der DNS-Zone des Tunnels, von dem Sie wissen, dass er intern auflöst, fragen Sie ihn einmal an und beobachten Sie, ob der Tunnel erscheint. Führen Sie dieselbe Abfrage zweimal aus: Der zweite Versuch nutzt den Cache-Pfad, und der Unterschied zwischen beiden sagt Ihnen, ob der Auslöser die Auflösung oder das Routing ist.

Prüfen Sie nach dem Hochfahren des Tunnels die beiden Schichten getrennt. netstat -rn -f inet und netstat -rn -f inet6 zeigen, wohin jedes Präfix zeigt, scutil --dns zeigt die Resolver-Reihenfolge und welche Schnittstelle welchen Resolver besitzt, und nettop -m route zeigt, welche Schnittstelle die Bytes getragen hat. Wenn der Tunnel oben und der Resolver korrekt ist, die Ressource aber weiter scheitert, hören Sie auf, die Regel zu bearbeiten; prüfen Sie die serverseitige Autorisierung und die Rückroute.

Wenn die Regel jemand anderem gehört

Wenn der Tunnel nach dem Trennen wieder erscheint, gehört die Regel meist zu einem Profil statt zu einer App: eine per MDM verteilte Konfiguration, ein übrig gebliebenes persönliches Profil oder ein von einem anderen Client installiertes Profil. sudo profiles show -type configuration plus eine Suche nach den On-Demand-Schlüsseln grenzt es ein, und der Entfernungspfad ist das Profil, nicht der Schalter in der Menüleiste. Das Löschen des Diensteintrags oder der App lässt die Regel zurück, und die nächste Installation erbt sie erneut.

Ein einziger Test klärt die Zuständigkeit: trennen, warten, den internen Namen erneut anfordern. Kommt der Tunnel zurück, arbeitet der Auslöser wie vorgesehen, und die offene Frage ist, wer ihn verwaltet und ob dieser Umfang der gewünschte ist.

Bevor Sie das als Fehler melden, gehen Sie dieselben fünf Prüfungen durch: Resolver-Adressen des Tunnels in der Payload vorhanden, ein Name, der nicht im Cache war, keine frühere Regel, die schon passte, ein AAAA-Pfad, den die Routenliste abdeckt, und die App innerhalb des Tunnelumfangs. Wenn alle fünf zutreffen, tut die Regel ihre Arbeit, und der Fehler liegt weiter hinten im Pfad.