VPN- und Proxy-Status einer verwalteten Arbeits-App richtig lesen

Eine Arbeits-App scheitert auf einem verwalteten Telefon, jemand prüft den VPN-Schalter, sieht ihn an und erklärt den Pfad für gesund. Hier brechen die meisten dieser Diagnosen ab, und das ist zu früh: Ein aktiver VPN-Transport sagt nicht, dass die Anfragen dieser App ihn genutzt haben, und der Proxy, der tatsächlich greift, kann pro App gelten oder durch eine PAC-Datei gewählt werden, statt in den Einstellungen aufzuscheinen. Beginne bei der konkreten App und dem Profil, die du untersuchst, und lies dann die Sicht der Plattform auf den Pfad.

Beginne bei der App und ihrem Profil

Eine App mit Arbeits-Badge läuft meist in einem eigenen Profil mit eigener Netzwerkrichtlinie. Ein persönlicher Browser auf demselben Telefon ist kein Beleg dafür, und ein Ergebnis vom Gerät einer Kollegin mit anderer Verwaltung auch nicht. Notiere, zu welchem Profil die App gehört, bevor du irgendetwas liest.

Liste in den Einstellungen die konfigurierten VPN-Einträge auf und notiere, wem jeder gehört. Bei Samsung-Builds verschieben sich die Menübeschriftungen zwischen den Versionen, beschreibe daher den Eintrag statt den Weg dorthin. Ein ausgegrauter oder verwalteter Eintrag gehört demjenigen, der das Gerät administriert; ihn versuchsweise abzuschalten ändert das, was du messen willst, und kann gegen die Richtlinie verstoßen.

Lies den Zustand, den die Plattform meldet

Innerhalb einer bestehenden Activity in deinem Support-Tooling, ab API 23, lässt sich der Netzwerkzustand lesen, ohne ein Byte zu senden. Der Aufruf benötigt die normale Manifest-Berechtigung ACCESS_NETWORK_STATE für das Lesen der Fähigkeiten.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Jeder Wert beantwortet eine enge Frage. Das aktive Netzwerk ist das Standardnetzwerk des aufrufenden Prozesses in diesem Moment. Die Fähigkeitsprüfung sagt dir, ob dieses Standardnetzwerk VPN-gestützt ist. Der Proxy-Aufruf meldet den effektiven Standard-HTTP-Proxy, und das zurückgegebene Objekt kann entweder einen statischen Proxy oder ein PAC-Skript beschreiben.

Wenn du die Ansicht pro Netzwerk statt der Standardansicht brauchst, lies die Link-Eigenschaften desselben Netzwerks und vergleiche mit cm.getLinkProperties(network)?.httpProxy. Ein von der Geräteverwaltung installierter Proxy erscheint im Standard-Proxy-Aufruf und nicht in den Link-Eigenschaften, was ein schneller Weg ist, einen richtlinienseitigen Proxy von einem vom Netzwerk ausgegebenen zu unterscheiden.

Behalte die Ausgabe in deinem Support-Kanal statt in einem öffentlichen Bericht. Proxy-Hostnamen, PAC-URLs und interne Suffixe verraten, wie deine Organisation den Verkehr lenkt, und nichts davon wird gebraucht, um den Fehler zu beschreiben.

Deute jedes Feld eng

Ein null-Netzwerk oder ein null-Fähigkeitsobjekt bedeutet, dass der Netzwerkzustand des Aufrufers nicht verfügbar war oder sich während des Lesens änderte. Es bedeutet nicht, dass es kein VPN gibt. Behandle es als unbekannt und lies erneut, nachdem die App in den Vordergrund kam, statt als negatives Ergebnis.

Ein VPN-Transport ist das Schwächste der positiven Merkmale. Jede App, die einen VpnService hält, erzeugt einen, auch eine lokale Filter-App, die deinen Verkehr nie irgendwohin schickt. Ein true-Wert sagt also, dass ein VPN-gestütztes Standardnetzwerk existiert, nicht dass der Ausgang deiner Organisation genutzt wurde und schon gar nicht, dass eine Inspektion stattfand.

Ein null-Standardproxy bedeutet, dass diese API für die effektive Konfiguration keinen Standard-HTTP-Proxy meldet. Es schließt sehr wenig aus: Eine App kann ihre eigene SOCKS-Einstellung mitführen, ihren eigenen HTTP-Client implementieren oder von einem Proxy am Gateway gesteuert werden, von dem das Gerät nie erfährt.

PAC ist der Fall, der eine Einzelwert-Antwort besiegt. Ein Skript kann ein Ziel über einen Proxy leiten und ein anderes direkt senden, sodass zwei Anfragen derselben App innerhalb einer Sekunde verschiedene Pfade nehmen können. Und eine App, die ihre Sockets an ein gewähltes Netzwerk bindet oder bindProcessToNetwork aufruft, muss dem Standard keineswegs folgen.

Was dieser Schnappschuss dir nicht sagen kann

Es ist keine Historie. Nichts hier zeichnet auf, welchen Pfad die fehlschlagende Anfrage nahm, und ein erfolgreiches Lesen nach dem Fehler ist kein Beleg über den Fehler. Es ist auch kein Inventar: Du bekommst das Standardnetzwerk des aufrufenden Prozesses, keine Liste der privaten Verbindungen jeder App.

Es sagt auch nichts darüber, was über dem Socket geschieht. Ein TLS-Handshake, der auf einem verwalteten Gerät scheitert, kann ein Problem des Trust-Stores, eine Pinning-Abweichung oder ein Name sein, den der Proxy ablehnt, und nichts davon erscheint in einem Konnektivitäts-Lesen.

Deshalb zählen die beiden Hälften zusammen: Der Schnappschuss engt ein, wo man schauen muss, und die eigene Diagnostik der App sagt, was tatsächlich gescheitert ist.

Melde es in einer Form, die ein Administrator nutzen kann

Gib die betroffene App, das Profil, den Zeitstempel und die genaue gescheiterte Stufe an: Namensauflösung, TCP-Verbindung, TLS-Handshake oder ein HTTP-Status. Füge die Schnappschuss-Werte so hinzu, wie sie gelesen wurden, mit Nullen als Nullen geschrieben statt als keins. Notiere, ob andere Apps im selben Profil auf dieselbe Weise scheitern, was ein App-Problem von einem profilweiten Pfadproblem trennt.

Dann höre auf und lass die Eigentümerin des Pfads antworten. Behandle ein Unternehmenszertifikat, eine Proxy-Adresse oder einen VPN-Eintrag nicht als Erlaubnis, die Verwaltung zu entfernen oder die genehmigte Route zu umgehen; das macht aus einem Supportfall einen Richtlinienvorfall.

Der Standard-Proxy-Vertrag ist kurz und lohnt ein einmaliges Lesen, weil er genau festlegt, welchen Proxy der Aufruf meldet, und jedes Überlesen dieses Schnappschusses beginnt mit der Annahme, er melde mehr.