Éin app dukkar opp to gonger på ein telefon med arbeidsprofil, og dei to kopiane er ikkje same subjekt. Eit VPN per app som er sett opp inne i éin kontekst, styrer instansen til den konteksten, og difor kan ei regel som nemner pakken framleis la den andre kopien vere urørt. Dette er ikkje ein feil å arbeide seg rundt, det er profilgrensa som gjer nettopp det ho vart laga for. Spørsmålet som er verdt å svare på, er kva kontekst som eig VPN-et og kva som eig appen du prøver å verne.

Eitt ikon, to installasjonar, to eigarar av policyen

Android gir arbeidsprofilen sin eigen styrte kontekst, komplett med separate apper, kontoar og policy, slik at startaren kan vise to oppføringar som deler namn og merke. Ei VPN-teneste som vert starta inne i éin kontekst, arbeider for brukarane av den konteksten, og det er mekanismen bak heile problemet. Ikonet fortel kva app du trykte på, ikkje kva profil trafikken som kjem ut høyrer til. Difor må eigaren lesast frå profilen og ikkje frå biletet.

Ei organisasjon kan òg tvinge fram alltid-på eller blokker-utan-VPN-åtferd for den styrte sida, noko som endrar kva som skjer når tunnelen er nede. Den personlege sida har inga slik garanti, med mindre du har bygd ei sjølv.

Kva ei liste over tillatne apper eigentleg tyder

Android si støtte for VPN per app er bygd på lister, dokumentert i rettleiinga om VPN-brukarar og arbeidsprofilar, og dei to listetypane har motsette standardverdiar. Ei tillaten liste tyder at berre dei namngjevne pakkane brukar tunnelen og alt anna er utelate, medan ei lista over ikkje-tillatne apper tyder at alt er med unnateke dei namngjevne pakkane. Snu du dette, har du bygd det motsette av den tiltenkte policyen medan innstillingsskjermen framleis ser truverdig ut. Lista vert vurdert inne i den konteksten der VPN-et køyrer, så eit pakkenamn som finst i begge profilar, passar berre med kopien i den konteksten. Ein pakke som ikkje står på lista i den andre profilen, er rett og slett ikkje denne VPN-saka.

Skriv ned åtferda for dei to eller tre appane som tel, fordi skilnaden mellom alt-unnteke og berre-desse avgjer om ein personleg app lek rundt tunnelen eller feilar lukka. Ein liten tabell slår eit avsnitt her: éi rad per profil, med listetype og standardverdien for alt anna.

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

Kva side som køyrer tunnelen, og under kven sin policy

Eit forbrukar-VPN opphevar ikkje kontrollane til organisasjonen i den styrte profilen, og eit arbeidsprofil-VPN er ikkje ein generell tunnel for personlege apper. Viss organisasjonen krev sin eigen klient for styrte apper, er den personlege klienten eit separat arrangement med sin eigen policy og sine eigne feilmåtar. Avgjer kva mekanisme som skal bere kva trafikk før du samanliknar resultat, elles måler du to system og kallar skilnaden ein feil. Innanfor sin eigen kontekst vinn den styrte sida vanlegvis, og det er den tiltenkte åtferda.

Det vanskelege tilfellet er ein styrt app som treng ei rute som den styrte policyen ikkje tilbyr. Det er ein førespurnad om unntak til organisasjonen, ikkje ein grunn til å slå av arbeidsprofilen.

Å teste den instansen du faktisk meinte

Start kopien du bryr deg om, og gransk førespurnaden innanfrå, fordi ein kontroll av den offentlege adressa i den personlege nettlesaren ikkje seier noko om arbeidsappen. Stadfest den innlogga kontoen og den interne namneløysinga kvar for seg, sidan eit internt namn kan henge saman med den styrte ruta medan offentleg nettlesing held fram andre stader. Skriv ned kva kopi som gav kva resultat i det augeblikket du testar, og set profilen i etiketten; eit skjermbilete med to like ikon er ikkje prov. Gjenta kontrollen etter ei ny tilkopling og etter at profilen er laga på nytt, fordi policyen kan verte brukt igjen i mellomtida.

Viss du ikkje kan seie kva kopi som svara, rett opp merkinga før du dreg noka slutning. Eit tvitydig resultat er verre enn ingen resultat, fordi det seinare vert sitert som om det avgjorde spørsmålet.

Dokumentere dekninga slik at neste test overlever

Skriv ned tre fakta saman for kvar kontekst: appinstansen, eigaren av policyen og den venta dekninga. Det er nok for neste person til å gjenta testen din utan å gisse på kva ikon dei starta. Legg til listetypen og standardverdien for pakkar som ikkje står på lista, fordi det er den delen folk oftast les feil.

Stadfest så eitt internt namn og éi ekstern adresse frå kvar side, og skriv ned kva som bør skje når den styrte sida blokkerer det personlege VPN-et. Ein telefon der ingen av sidene er dekte medan begge ser tilkopla ut, er feilen det er verdt å designe mot. Når begge profilane verkeleg treng ein tunnel, planlegg to arrangement i staden for éi smart regel.

Relaterte artiklar