Arbeits-App verlangt VPN? Prüfen Sie zuerst diese drei Ebenen

Die Meldung sagt, die App brauche ein VPN, doch meist meldet die App ein Symptom, statt das zu benennen, was sie blockiert hat. Drei verschiedene Verursacher können diesen Satz erzeugen: der private Dienst, mit dem die App spricht, der eigene Richtliniencode der App und die Geräteverwaltungsebene, die das Arbeitsprofil steuert. Wer fragt, ändert, was Sie tun sollten, und nur einer der drei lässt sich durch Verbinden eines Tunnels beheben. Erst den Verursacher zu finden erspart Ihnen die Neuinstallation eines Clients, der nie das Problem war.

Was die App selbst prüfen kann

Bevor Sie eine versteckte Plattformregel annehmen, bedenken Sie, dass eine normale App sehen kann, ob ein VPN-Transport aktiv ist. ConnectivityManager meldet Netze mit TRANSPORT_VPN, und das Fehlen von NET_CAPABILITY_NOT_VPN sagt jedem Aufrufer, dass der aktuelle Pfad getunnelt ist. Ein Entwickler, der den Betrieb außerhalb eines Tunnels verweigern will, kann das mit öffentlichen APIs und ganz ohne Unternehmenswerkzeuge tun.

Was die App so nicht sehen kann, ist, wessen VPN es ist. Ein Transport-Flag sagt, dass ein Tunnel existiert, nicht dass er dort endet, wo Ihre Organisation es erwartet.

Der Dienstpfad: private Namen und Adressen

Die häufigste ehrliche Version der Meldung ist gar keine Richtlinienprüfung. Die App löst einen internen Hostnamen wie ein Wiki oder einen API-Endpunkt auf, der nur innerhalb der Unternehmens-DNS-Ansicht existiert, und die Auflösung scheitert, bevor irgendein Richtliniencode läuft. Der Tunnel kann stehen und allgemeinen Internetverkehr durchlassen, während geteiltes DNS diesen Namen an einen Resolver schickt, der nie davon gehört hat.

Die Symptome sind hier eng. Ein Host scheitert, die übrigen Netzwerkaufrufe der App funktionieren, und der Fehler tritt bei einer Namensauflösung auf, nicht beim Start. Interne Zertifikate fügen einen zweiten Fehlermodus hinzu, denn eine an die CA der Organisation gebundene App lehnt ein öffentliches Zertifikat ab, selbst wenn die Pakete fließen.

Ein beliebiges kommerzielles VPN zu verbinden behebt nichts davon. Es ändert Ihre Ausgangsadresse und lässt den internen Namen genauso unauflösbar.

Die App-Richtlinienebene

Eine App kann auch ihr eigenes Tor mitbringen. Verwaltete Konfigurationen erlauben der Organisation, Schlüssel-Wert-Paare zu pushen, die die App deklariert, und die App liest sie über RestrictionManager. Ein Schlüssel wie ein erforderlicher Profilname oder eine Liste erlaubter Netze ist ganz Entwicklerdesign, im Anwendungscode durchgesetzt mit dem Fehlertext, den dieser Code wählt.

Diese Ebene ist der Ort, an dem die Formulierung es meist verrät. Erscheint die Meldung sofort beim Start, vor jedem Netzwerkaufruf, und nennt eine Richtlinie, ein Profil oder einen Administrator, sehen Sie wahrscheinlich Anwendungslogik statt eines verworfenen Pakets.

Dieselbe Einschränkung auf einem privaten Gerät zu lesen ist eine Sackgasse. Nicht verwaltete Geräte haben keine Einschränkungen zum Lesen, also fällt die App auf den Standard zurück, mit dem sie gebaut wurde.

Die Plattformebene: Always-on und Sperre

Geräteverwaltung fügt Durchsetzung hinzu, die die App nicht überschreiben kann. Ein Geräterichtlinien-Controller kann setAlwaysOnVpnPackage für das Arbeitsprofil aufrufen, optional mit aktivierter Sperre, und sobald die Sperre an ist, verweigert die Plattform Verkehr, der nicht durch dieses Paket geht. Die Blockade zeigt sich als Systemzustand statt als App-Fehler: andere Apps im Profil erreichen das Netzwerk ebenfalls nicht mehr.

Der Umfang zählt. Always-on-VPN wird pro Benutzer konfiguriert, also deckt ein Arbeitsprofil-Paket Ihr persönliches Profil nicht ab, und ein persönliches VPN erfüllt das Arbeitsprofil-Paket nicht. Zwei Profile, zwei unabhängige Netzwerkrichtlinien, ein Gerät.

Das ist auch die einzige Ebene, auf der ein unabhängiges VPN nicht helfen kann, weil die Richtlinie ein bestimmtes Paket nennt.

Die drei auseinanderhalten

Gehen Sie die Signaturen der Reihe nach durch und halten Sie bei der ersten an, die passt. Ein Hostname scheitert, während alles andere auflöst, deutet auf den Dienstpfad. Eine sofortige Ablehnung beim Start mit Richtlinienformulierung deutet auf Anwendungslogik. Ein ganzes Profil verliert die Verbindung, wann immer der genehmigte Client trennt, deutet auf die Sperre. Und eine App, die jeden Tunnel akzeptiert, prüft das Transport-Flag, nicht die Identität Ihrer Organisation.

Nützliche Belege: der genaue Text und sein Zeitpunkt, ob andere Apps im selben Profil noch Verbindung haben, ob der private Name innerhalb des genehmigten Tunnels auflöst und ob das Gerät ein Arbeitsabzeichen für die geöffnete App zeigt.

Was in die Supportanfrage gehört

Eine Anfrage, die die Ebene nennt, wird beim ersten Versuch richtig geroutet. Etwa so: die Arbeitsprofil-App öffnet, die Ressourcenliste scheitert, nachdem das genehmigte VPN verbindet, die private Namensauflösung scheitert in der erlaubten Diagnose, und andere Apps im Profil funktionieren weiter. Das liest sich als Routen- oder Resolverproblem und überspringt die Konto-Reset-Schleife.

Fehlt das genehmigte VPN ganz, ist der unterstützte Weg die Registrierung oder Neubereitstellung über Ihren Administrator. Das Managementprofil zu entfernen, einen unabhängigen Client zu installieren oder den Netzwerkzustand vorzutäuschen ändert die Sicherheitsanordnung, statt sie wiederherzustellen.

Beginnen Sie bei der Ebene, nicht beim Client. Die drei Signaturen oben klären es meist in einer Sitzung.