En app vises to gange på en telefon med en arbejdsprofil, og de to kopier er ikke det samme subjekt. Et appbaseret VPN, der konfigureres inde i én kontekst, styrer den konteksts instans, og derfor kan en regel, der navngiver pakken, stadig lade den anden kopi være urørt. Det er ikke en fejl, man skal arbejde uden om, det er profilgrænsen, der gør præcis det, den blev designet til. Spørgsmålet, der er værd at besvare, er, hvilken kontekst der ejer VPN'et, og hvilken der ejer den app, du prøver at beskytte.

Ét ikon, to installationer, to ejere af politikken

Android giver arbejdsprofilen sin egen administrerede kontekst, komplet med separate apps, konti og politik, så launcheren kan vise to poster, der deler et navn og et mærke. En VPN-tjeneste, der startes inde i én kontekst, arbejder for brugerne af den kontekst, og det er mekanismen bag hele problemet. Ikonet fortæller dig, hvilken app du trykkede på, ikke hvilken profil den resulterende trafik tilhører. Derfor skal ejeren læses fra profilen og ikke fra billedet.

En organisation kan også gennemtvinge always-on eller bloker-uden-VPN for den administrerede side, hvilket ændrer, hvad der sker, når tunnelen er nede. Den personlige side har ingen sådan garanti, medmindre du selv har bygget en.

Hvad en liste over tilladte apps egentlig betyder

Androids understøttelse af appbaseret VPN er bygget op omkring lister, dokumenteret i vejledningen om VPN-brugere og arbejdsprofiler og de to listetyper har modsatte standardværdier. En liste over tilladte apps betyder, at kun de navngivne pakker bruger tunnelen, og alt andet er udelukket, mens en liste over ikke-tilladte apps betyder, at alt er inkluderet undtagen de navngivne pakker. Vender du det om, har du bygget det modsatte af den tilsigtede politik, mens indstillingsskærmen stadig ser rimelig ud. Listen evalueres i den kontekst, hvor VPN'et kører, så et pakkenavn, der findes i begge profiler, matcher kun kopien i den kontekst. En pakke, der ikke er nævnt i den anden profil, kommer dette VPN ganske enkelt ikke ved.

Skriv adfærden ned for de to eller tre apps, der betyder noget, for forskellen mellem alt-undtagen og kun-disse afgør, om en personlig app lækker uden om tunnelen eller fejler lukket. En lille tabel slår et afsnit her: én række for hver profil, med listetype og standarden for alt andet.

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

Hvilken side der kører tunnelen, og under hvis politik

Et forbruger-VPN ophæver ikke organisationens kontroller i den administrerede profil, og et arbejdsprofil-VPN er ikke en generel tunnel for personlige apps. Hvis organisationen kræver sin egen klient til administrerede apps, er den personlige klient en separat ordning med sin egen politik og sine egne fejltilstande. Beslut, hvilken mekanisme der skal bære hvilken trafik, før du sammenligner resultater, ellers måler du to systemer og kalder forskellen en fejl. Inden for sin egen kontekst vinder den administrerede side som regel, og det er den tilsigtede adfærd.

Det akavede tilfælde er en administreret app, der har brug for en rute, som den administrerede politik ikke stiller til rådighed. Det er en undtagelsesanmodning til organisationen, ikke en grund til at deaktivere arbejdsprofilen.

Test den instans, du faktisk mente

Start den kopi, du bekymrer dig om, og undersøg anmodningen indefra, for en kontrol af den offentlige adresse i den personlige browser siger intet om arbejdsappen. Kontroller den indloggede konto og den interne navneopløsning separat, da et internt navn kan afhænge af den administrerede rute, mens offentlig browsing bliver et andet sted. Noter, hvilken kopi der gav hvilket resultat i det øjeblik, du tester, og skriv profilen i etiketten; et skærmbillede med to identiske ikoner er ikke bevis. Gentag kontrollen efter en genoprettet forbindelse og efter profilen er genskabt, fordi politikken kan blive anvendt igen indimellem.

Hvis du ikke kan afgøre, hvilken kopi der svarede, så ret mærkningen, før du drager nogen konklusion. Et tvetydigt resultat er værre end intet resultat, fordi det senere bliver citeret, som om det afgjorde spørgsmålet.

Dokumentér dækningen, så næste test overlever

Noter tre fakta sammen for hver kontekst: appinstansen, politikens ejer og den forventede dækning. Det er nok til, at den næste person kan genskabe din test uden at gætte, hvilket ikon de startede. Tilføj listetypen og standarden for pakker, der ikke er nævnt, fordi det er den del, folk oftest læser forkert.

Kontroller derefter ét internt navn og én ekstern adresse fra hver side, og skriv ned, hvad der skal ske, når den administrerede side blokerer det personlige VPN. En telefon, hvor ingen af siderne er dækket, mens begge ser forbundne ud, er den fejl, det er værd at designe imod. Når begge profiler virkelig har brug for en tunnel, planlæg to ordninger i stedet for én smart regel.

Relaterede artikler