Warum ein App-basiertes VPN die Arbeitskopie einer Android-App nicht erfasst

Eine App erscheint auf einem Telefon mit Arbeitsprofil zweimal, und die beiden Kopien sind nicht dasselbe Subjekt. Ein App-basiertes VPN, das in einem Kontext eingerichtet ist, steuert die Instanz dieses Kontexts, weshalb eine Regel, die das Paket nennt, die andere Kopie dennoch unberührt lassen kann. Das ist kein Fehler, den man umgehen müsste, sondern die Profilgrenze, die genau das tut, wofür sie entworfen wurde. Die Frage, die es zu beantworten gilt, ist, welcher Kontext das VPN besitzt und welcher die App, die du schützen willst.

Ein Symbol, zwei Installationen, zwei Eigentümer der Richtlinie

Android gibt dem Arbeitsprofil einen eigenen verwalteten Kontext, samt getrennten Apps, Konten und Richtlinien, sodass der Launcher zwei Einträge zeigen kann, die sich einen Namen und ein Abzeichen teilen. Ein VPN-Dienst, der in einem Kontext gestartet wird, arbeitet für die Nutzer dieses Kontexts, und das ist der Mechanismus hinter dem ganzen Problem. Das Symbol sagt dir, welche App du angetippt hast, nicht, zu welchem Profil der daraus entstehende Datenverkehr gehört. Deshalb muss der Eigentümer aus dem Profil gelesen werden und nicht aus dem Bild.

Eine Organisation kann für die verwaltete Seite außerdem Always-on- oder Blockieren-ohne-VPN-Verhalten erzwingen, was ändert, was passiert, wenn der Tunnel unten ist. Die private Seite hat keine solche Garantie, es sei denn, du hast selbst eine gebaut.

Was eine Liste erlaubter Apps tatsächlich bedeutet

Androids Unterstützung für App-basierte VPNs baut auf Listen auf, dokumentiert im Leitfaden zu VPN-Nutzern und Arbeitsprofilen und die beiden Listentypen haben entgegengesetzte Standardwerte. Eine Liste der erlaubten Apps bedeutet, dass nur die genannten Pakete den Tunnel nutzen und alles andere ausgeschlossen ist, während eine Liste der nicht erlaubten Apps bedeutet, dass alles enthalten ist außer den genannten Paketen. Vertauschst du das, hast du das Gegenteil der beabsichtigten Richtlinie gebaut, während der Einstellungsbildschirm noch plausibel aussieht. Die Liste wird in dem Kontext ausgewertet, in dem das VPN läuft, ein in beiden Profilen vorhandener Paketname trifft also nur die Kopie in jenem Kontext. Ein nicht gelistetes Paket im anderen Profil geht dieses VPN schlicht nichts an.

Schreib das Verhalten für die zwei oder drei Apps auf, die zählen, denn der Unterschied zwischen alles-außer und nur-diese entscheidet, ob eine private App am Tunnel vorbei leckt oder geschlossen scheitert. Eine kleine Tabelle schlägt hier einen Absatz: eine Zeile pro Profil, mit Listentyp und dem Standard für alles andere.

Welche Seite den Tunnel betreibt, und unter wessen Richtlinie

Ein Verbraucher-VPN hebt die Kontrollen der Organisation im verwalteten Profil nicht auf, und ein Arbeitsprofil-VPN ist kein allgemeiner Tunnel für private Apps. Wenn die Organisation für verwaltete Apps ihren eigenen Client verlangt, ist der private Client eine getrennte Vereinbarung mit eigener Richtlinie und eigenen Fehlerarten. Entscheide, welcher Mechanismus welchen Datenverkehr tragen soll, bevor du Ergebnisse vergleichst, sonst misst du zwei Systeme und nennst den Unterschied einen Fehler. Innerhalb des eigenen Kontexts gewinnt in der Regel die verwaltete Seite, und das ist das beabsichtigte Verhalten.

Der unangenehme Fall ist eine verwaltete App, die eine Route braucht, die die verwaltete Richtlinie nicht bereitstellt. Das ist ein Ausnahmeantrag an die Organisation, kein Grund, das Arbeitsprofil zu deaktivieren.

Die Instanz testen, die du tatsächlich meinst

Starte die Kopie, die dich interessiert, und prüfe die Anfrage von innen, denn eine Prüfung der öffentlichen Adresse im privaten Browser sagt nichts über die Arbeits-App aus. Prüfe das angemeldete Konto und die interne Namensauflösung getrennt, da ein interner Name von der verwalteten Route abhängen kann, während das öffentliche Surfen woanders bleibt. Notiere im Moment des Tests, welche Kopie welches Ergebnis erzeugt hat, und schreib das Profil ins Etikett; ein Screenshot mit zwei identischen Symbolen ist kein Beleg. Wiederhole die Prüfung nach einem erneuten Verbinden und nachdem das Profil neu erstellt wurde, weil die Richtlinie dazwischen erneut greifen kann.

Wenn du nicht sagen kannst, welche Kopie geantwortet hat, repariere die Beschriftung, bevor du irgendeinen Schluss ziehst. Ein mehrdeutiges Ergebnis ist schlimmer als kein Ergebnis, weil es später zitiert wird, als hätte es die Frage geklärt.

Abdeckung dokumentieren, damit der nächste Test überlebt

Halte für jeden Kontext drei Fakten zusammen fest: die App-Instanz, den Eigentümer der Richtlinie und die erwartete Abdeckung. Das reicht der nächsten Person, um deinen Test nachzuvollziehen, ohne zu raten, welches Symbol sie gestartet hat. Ergänze den Listentyp und den Standard für nicht gelistete Pakete, denn das ist der Teil, der am häufigsten falsch gelesen wird.

Prüfe dann je einen internen Namen und eine externe Adresse von jeder Seite, und schreib auf, was passieren soll, wenn die verwaltete Seite das private VPN blockiert. Ein Telefon, bei dem keine Seite abgedeckt ist, während beide verbunden aussehen, ist der Fehler, gegen den man entwerfen sollte. Wenn beide Profile wirklich einen Tunnel brauchen, plane zwei Vereinbarungen statt einer cleveren Regel.