Eén app verschijnt twee keer op een telefoon met een werkprofiel, en de twee kopieën zijn niet hetzelfde subject. Een VPN per app die binnen één context is ingesteld, beheert de instantie van die context, en daarom kan een regel die het pakket noemt de andere kopie nog steeds ongemoeid laten. Dit is geen fout omheen te werken, het is de profielgrens die doet waarvoor hij ontworpen is. De vraag die het antwoord waard is, is welke context de VPN bezit en welke de app bezit die je probeert te beschermen.

Eén pictogram, twee installaties, twee eigenaren van het beleid

Android geeft het werkprofiel een eigen beheerde context, compleet met aparte apps, accounts en beleid, zodat de launcher twee items kan tonen die een naam en een badge delen. Een VPN-dienst die binnen één context start, werkt voor de gebruikers van die context, en dat is het mechanisme achter het hele probleem. Het pictogram vertelt je welke app je hebt aangetikt, niet bij welk profiel het resulterende verkeer hoort. Daarom moet de eigenaar uit het profiel worden gelezen en niet uit het plaatje.

Een organisatie kan voor de beheerde kant ook always-on of blokkeren-zonder-VPN afdwingen, wat verandert wat er gebeurt als de tunnel platligt. De persoonlijke kant heeft zo'n garantie niet, tenzij je er zelf een hebt gebouwd.

Wat een lijst met toegestane apps echt betekent

De ondersteuning voor VPN per app in Android is gebouwd rond lijsten, gedocumenteerd in de handleiding over VPN-gebruikers en werkprofielen en de twee lijsttypen hebben tegengestelde standaardwaarden. Een lijst met toegestane apps betekent dat alleen de genoemde pakketten de tunnel gebruiken en al het andere wordt uitgesloten, terwijl een lijst met niet-toegestane apps betekent dat alles is inbegrepen behalve de genoemde pakketten. Heb je dat omgedraaid, dan heb je het tegenovergestelde van het bedoelde beleid gebouwd terwijl het instellingenscherm er nog steeds plausibel uitziet. De lijst wordt geëvalueerd binnen de context waarin de VPN draait, dus een pakketnaam die in beide profielen voorkomt, komt alleen overeen met de kopie in die context. Een niet-vermeld pakket in het andere profiel gaat deze VPN simpelweg niets aan.

Schrijf het gedrag op voor de twee of drie apps die ertoe doen, want het verschil tussen alles-behalve en alleen-deze bepaalt of een persoonlijke app langs de tunnel lekt of gesloten faalt. Een kleine tabel verslaat hier een alinea: één rij per profiel, met het lijsttype en de standaard voor al het andere.

ContextList typeApps not named
Work profileallowed onlyexcluded from the tunnel
Personal profiledisallowedincluded in the tunnel

Welke kant de tunnel draait, en onder wiens beleid

Een consumenten-VPN haalt de controles van de organisatie niet weg uit het beheerde profiel, en een werkprofiel-VPN is geen algemene tunnel voor persoonlijke apps. Als de organisatie voor beheerde apps haar eigen client vereist, is de persoonlijke client een aparte regeling met een eigen beleid en eigen faalwijzen. Bepaal welk mechanisme welk verkeer hoort te dragen voordat je resultaten vergelijkt, anders meet je twee systemen en noem je het verschil een fout. Binnen de eigen context wint de beheerde kant meestal, en dat is het bedoelde gedrag.

Het lastige geval is een beheerde app die een route nodig heeft die het beheerde beleid niet biedt. Dat is een uitzonderingsverzoek aan de organisatie, geen reden om het werkprofiel uit te schakelen.

De instantie testen die je echt bedoelde

Start de kopie die je belangrijk vindt en bekijk het verzoek van binnenuit, want een controle van het openbare adres in de persoonlijke browser zegt niets over de werk-app. Controleer het aangemelde account en de interne naamresolutie apart, omdat een interne naam kan afhangen van de beheerde route terwijl het openbare browsen elders blijft. Noteer op het moment van de test welke kopie welk resultaat opleverde, en zet het profiel in het label; een schermafbeelding met twee identieke pictogrammen is geen bewijs. Herhaal de controle na een nieuwe verbinding en nadat het profiel opnieuw is aangemaakt, omdat het beleid tussendoor opnieuw kan worden toegepast.

Als je niet kunt zeggen welke kopie heeft geantwoord, repareer dan de labeling voordat je een conclusie trekt. Een dubbelzinnig resultaat is erger dan geen resultaat, omdat het later wordt aangehaald alsof het de vraag heeft beslecht.

Dekking documenteren zodat de volgende test overleeft

Leg voor elke context drie feiten samen vast: de app-instantie, de eigenaar van het beleid en de verwachte dekking. Dat is genoeg voor de volgende persoon om je test te reproduceren zonder te raden welk pictogram die heeft gestart. Voeg het lijsttype en de standaard voor niet-vermelde pakketten toe, want dat is het deel dat mensen het vaakst verkeerd lezen.

Controleer dan één interne naam en één extern adres vanaf elke kant, en schrijf op wat er moet gebeuren als de beheerde kant de persoonlijke VPN blokkeert. Een telefoon waarbij geen van beide kanten is gedekt terwijl beide verbonden lijken, is de storing waar je tegen moet ontwerpen. Als beide profielen echt een tunnel nodig hebben, plan dan twee regelingen in plaats van één slimme regel.

Gerelateerde artikelen