Per-App-VPN für verwaltete iPhone-Apps: Was geroutet wird und was nicht

Per-App-VPN auf dem iPhone ist kein Schalter für das ganze Telefon. Es ist eine Zuordnung zwischen einer verwalteten App und einer VPN-Payload, die beim Ausrollen der App entsteht, und der Verkehr aller anderen Apps behält die bisherige Route. Deshalb verhält sich dasselbe Telefon inkonsistent: Die Arbeits-App öffnet eine interne Seite, während Safari denselben Host nicht erreicht, oder der Tunnel kommt gar nicht hoch und die App meldet einen Timeout, der nach falschen Zugangsdaten aussieht. Die Prüfungen laufen von der weitesten Ursache nach unten, also stoppen Sie bei der ersten, die fehlschlägt.

Prüfen Sie zuerst die Payload und den App-Eintrag

Die Zuordnung lebt in zwei Objekten, nicht in einem. Die VPN-Payload definiert den Tunnel: Typ, Server, Authentifizierung, DNS und die Bundle-ID des Anbieters, wenn ein eigener Client verwendet wird. Der App-Eintrag verweist auf diese Payload, und die meisten Management-Konsolen bieten das als Per-App-Option in der App-Konfiguration an, mit einem Namen nahe Per-App VPN. Eine Payload, auf die keine App zeigt, routet nichts pro App; sie verhält sich wie ein gewöhnlicher Tunnel, den jemand von Hand starten muss.

Lesen Sie beide Objekte, bevor Sie das Telefon anfassen. Bestätigen Sie, dass die App-Konfiguration auf die Payload verweist, die Sie testen, und nicht auf eine ältere Kopie, denn doppelte Payloads mit fast gleichen Namen sind nach einer Migration häufig, und die App zeigt gern auf die ausgemusterte. Bestätigen Sie dann, dass die Konfiguration das Gerät erreicht hat: Einstellungen, Allgemein, VPN und Geräteverwaltung müssen sie als installiertes Profil zeigen. Die VPN-Liste dort ist nicht der Test. Ein Per-App-Dienst hat meist keinen manuellen Schalter, eine korrekt ausgerollte Konfiguration erscheint also möglicherweise nie unter den startbaren VPNs. Die Abwesenheit zeigt sich im App-Eintrag und darin, ob der Tunnel bei der ersten Anfrage der App startet.

Eine Bedingung erklärt viele Tickets: Dieses Modell verlangt, dass die App über die Verwaltung kommt. Eine per Sideload installierte oder privat gekaufte Kopie erhält die Zuordnung nicht, selbst wenn ihre Bundle-ID übereinstimmt. Apples Deployment-Leitfaden zu VPN beschreibt das Payload-Modell dahinter (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).

Bestätigen Sie, dass die installierte App die verwaltete Kopie ist

Die Zuordnung folgt der installierten, verwalteten App. Wenn jemand sie unter einer privaten Apple ID aus dem App Store neu installiert, sie durch einen neu signierten Enterprise-Build ersetzt hat oder das Gerät neu registriert wurde und die App über einen anderen Kanal zurückkam, kann der Tunnel unten bleiben, während die App selbst völlig normal aussieht.

Testen Sie per Vergleich, nicht per Einzelbeobachtung. Im Verwaltungsinventar muss die App für dieses Gerät als verwaltet erscheinen, mit dem VPN-Mapping im Eintrag. Auf dem Telefon muss der Tunnel hochkommen, wenn die App gestartet wird und ihre erste Anfrage hinausgeht, nicht nur wenn jemand eine separate manuelle Konfiguration in den Einstellungen startet. Wenn das Starten der App nichts ändert, die manuelle Konfiguration aber schon, ist die App überhaupt nicht an einen Per-App-Tunnel gebunden.

Updates zählen: Ein über die Verwaltung eingespieltes Update behält das Mapping, eine vom Nutzer angestoßene Neuinstallation kann es verlieren. Wenn die Beschwerde von einem Update stammt, prüfen Sie den App-Eintrag vor dem Netzwerk.

Prüfen Sie, was der Tunnel übernehmen darf

Ein Per-App-Tunnel wird nach Quell-App gewählt, die Standardroute des Telefons gehört also weiterhin Wi-Fi oder Mobilfunk. OverridePrimary ist der Schlüssel, der das ändert. Setzt ein Profil ihn, verhält sich der Tunnel wie ein voller Tunnel, und jede App erbt ihn, sodass alles über das VPN zu einer Profilfrage statt zu einem App-Fehler wird.

On-Demand-Regeln entscheiden über die Beständigkeit. OnDemandEnabled plus Regelsatz sorgen dafür, dass der Tunnel zurückkommt, wenn die App Verkehr sendet, einen Wechsel von Wi-Fi zu Mobilfunk übersteht oder fällt, sobald die App in den Hintergrund geht. Ein Deployment, das sich verbindet und dann still stirbt, hat meist eine Regel, die nur auf eine Probe passt, die nie auslöst, während die App untätig ist.

Dann lesen Sie die Routenseite ehrlich. Liefert ein Anbieter- oder Vendor-Profil eine Include-Liste, trägt ein Tunnel mit nur 10.20.0.0/16 keinen Dienst in 10.30.0.0/16; das ist die Liste, die ihre Aufgabe erfüllt, kein Per-App-Fehler. Die eingebaute iOS-Payload hat keine Include-Liste. Ohne eine folgt die Aufteilung den Anbieter-Standards und IncludeAllNetworks, nicht einer versteckten Liste.

Testen Sie die App und dann, was sie verlässt

Testen Sie mit einem Namen, nicht nur mit einer Adresse. Die Auflösung eines internen Hosts in der verwalteten App beweist, dass auch DNS durch den Tunnel lief, denn die Payload bestimmt, welcher Resolver antwortet und welche Suchdomänen gelten. Das Routing kann perfekt sein, während die Namensauflösung scheitert, und die zwei Symptome deuten auf unterschiedliche Einstellungen.

Testen Sie dann die Grenze von beiden Seiten. Eine private App oder Safari sollte eine gewöhnliche öffentliche Seite erreichen und die Betreiber- oder Heimadresse melden, während die verwaltete App den internen Dienst erreicht. Wenn beide dieselbe öffentliche Adresse melden, ist der Tunnel nicht mehr pro App, was der App-Eintrag auch behauptet.

Flows, die die App verlassen, erzeugen die verwirrten Tickets. Ein Link, der in Safari öffnet, ein Dokument, das über das Teilen-Menü übergeben wird, oder ein SSO-Login, das in einen Browser wechselt, verlässt den App-Prozess und damit den Tunnel. Ein in der App dargestelltes Login wird meist der App zugerechnet, ein eingebettetes Login kann also gelingen, wo dieselbe URL in Safari scheitert; prüfen Sie das, statt es anzunehmen. Ist der Identitätsanbieter nur über den Tunnel erreichbar, halten Sie das Login entweder in der App oder nehmen Sie die Anbieter-Domain in die Safari-Domains der Payload auf, damit passender Safari-Verkehr erfasst wird.

Ordnen Sie das Symptom der Schicht zu

Die Fehlerform sagt Ihnen, welche Prüfung Sie wiederholen müssen.

Hinter den mittleren Zeilen stehen zwei Details: Ein Per-App-Tunnel kann gesund sein und trotzdem ein Subnetz verfehlen, das keine Anbieterliste enthält, und ein verwaltetes Telefon kann mehr als eine VPN-Konfiguration halten, also bestätigen Sie, an welche die App gebunden ist, statt anzunehmen, es sei die, die Sie lesen.

Beheben Sie in dieser Reihenfolge: App-Eintrag korrigieren, sodass er auf die aktive Payload verweist, App über die Verwaltung neu installieren, bestätigen, dass der Tunnel bei der ersten Anfrage startet, dann Namens- und Grenztests wiederholen. Kann die erste Anfrage gar keinen Tunnel starten, stoppen Sie und prüfen Sie die Anbieterseite, denn ein eigener Client braucht seine Network Extension vorhanden und ihre ID passend zur installierten App.

Geben Sie drei Fakten statt eines Screenshots zurück: auf welche Payload der App-Eintrag verweist, ob die Einstellungen sie als installiertes Profil zeigen und was die fehlgeschlagene Anfrage war, ein Name, eine Adresse oder eine Browserübergabe. Diese drei Antworten trennen einen Deployment-Fehler von einem Routingfehler, und der Nächste kann handeln, ohne die Diagnose zu wiederholen.