Varför ett appbaserat VPN missar arbetskopian av en Android-app
En arbetsprofil är en separat hanterad kontext, så ett appbaserat VPN i en profil kan lämna den personliga kopian orörd. Kontrollera ägaren innan du testar.
En app dyker upp två gånger på en telefon med arbetsprofil, och de två kopiorna är inte samma subjekt. Ett appbaserat VPN som konfigureras i en kontext styr den kontextens instans, vilket är varför en regel som namnger paketet ändå kan lämna den andra kopian orörd. Det här är ingen bugg att kringgå, det är profilgränsen som gör precis det den konstruerades för. Frågan som är värd att besvara är vilken kontext som äger VPN:et och vilken som äger appen du försöker skydda.
En ikon, två installationer, två ägare av policyn
Android ger arbetsprofilen en egen hanterad kontext, komplett med separata appar, konton och policy, så att startskärmen kan visa två poster som delar namn och märke. En VPN-tjänst som startas i en kontext arbetar för användarna i den kontexten, och det är mekanismen bakom hela problemet. Ikonen säger vilken app du tryckte på, inte vilken profil trafiken som blir resultatet tillhör. Därför måste ägaren läsas ur profilen och inte ur bilden.
En organisation kan också tvinga fram always-on eller blockera-utan-VPN för den hanterade sidan, vilket ändrar vad som händer när tunneln ligger nere. Den personliga sidan har ingen sådan garanti om du inte har byggt en själv.
Vad en lista över tillåtna appar faktiskt betyder
Androids stöd för appbaserade VPN bygger på listor, dokumenterat i guiden för VPN-användare och arbetsprofiler och de två listtyperna har motsatta standardvärden. En lista över tillåtna appar innebär att bara de namngivna paketen använder tunneln och allt annat utesluts, medan en lista över otillåtna appar innebär att allt ingår utom de namngivna paketen. Får du det bakvänt har du byggt motsatsen till den avsedda policyn medan inställningsskärmen fortfarande ser rimlig ut. Listan utvärderas i den kontext där VPN:et körs, så ett paketnamn som finns i båda profilerna matchar bara kopian i den kontexten. Ett paket som inte finns med i den andra profilen angår helt enkelt inte det här VPN:et.
Skriv ner beteendet för de två eller tre appar som spelar roll, för skillnaden mellan allt-utom och bara-dessa avgör om en personlig app läcker runt tunneln eller misslyckas stängt. En liten tabell slår en paragraf här: en rad per profil, med listtyp och standarden för allt annat.
| Context | List type | Apps not named |
|---|---|---|
| Work profile | allowed only | excluded from the tunnel |
| Personal profile | disallowed | included in the tunnel |
Vilken sida som kör tunneln, och under vems policy
Ett konsument-VPN upphäver inte organisationens kontroller i den hanterade profilen, och ett arbetsprofil-VPN är inte en allmän tunnel för personliga appar. Om organisationen kräver sin egen klient för hanterade appar är den personliga klienten en separat överenskommelse med egen policy och egna felbeteenden. Bestäm vilken mekanism som ska bära vilken trafik innan du jämför resultat, annars mäter du två system och kallar skillnaden en bugg. Inom sin egen kontext vinner den hanterade sidan oftast, och det är det avsedda beteendet.
Det besvärliga fallet är en hanterad app som behöver en rutt som den hanterade policyn inte tillhandahåller. Det är en undantagsbegäran till organisationen, inte ett skäl att stänga av arbetsprofilen.
Testa den instans du faktiskt menade
Starta kopian du bryr dig om och granska begäran inifrån, för en kontroll av den offentliga adressen i den personliga webbläsaren säger ingenting om arbetsappen. Verifiera det inloggade kontot och den interna namnmatchningen separat, eftersom ett internt namn kan bero på den hanterade rutten medan det offentliga surfandet stannar någon annanstans. Notera vilken kopia som gav vilket resultat i testögonblicket, och sätt profilen i etiketten; en skärmbild med två identiska ikoner är inget bevis. Upprepa kontrollen efter en återanslutning och efter att profilen har återskapats, eftersom policyn kan tillämpas igen däremellan.
Om du inte kan avgöra vilken kopia som svarade, fixa märkningen innan du drar någon slutsats. Ett tvetydigt resultat är värre än inget resultat, eftersom det citeras senare som om det avgjorde frågan.
Dokumentera täckningen så att nästa test överlever
Anteckna tre fakta tillsammans för varje kontext: appinstansen, policyägaren och den förväntade täckningen. Det räcker för nästa person att återskapa ditt test utan att gissa vilken ikon den startade. Lägg till listtypen och standarden för paket som inte finns med, eftersom det är den del som folk oftast läser fel.
Verifiera sedan ett internt namn och en extern adress från varje sida, och skriv ner vad som ska hända när den hanterade sidan blockerar det personliga VPN:et. En telefon där ingen av sidorna täcks medan båda ser anslutna ut är det fel som är värt att konstruera mot. När båda profilerna verkligen behöver en tunnel, planera två arrangemang i stället för en smart regel.