Hvorfor et appbasert VPN bommer på arbeidskopien av en Android-app

Én app dukker opp to ganger på en telefon med arbeidsprofil, og de to kopiene er ikke samme subjekt. Et appbasert VPN som konfigureres inne i én kontekst, styrer den kontekstens instans, og derfor kan en regel som navngir pakken fortsatt la den andre kopien være urørt. Dette er ikke en feil å arbeide seg rundt, det er profilgrensen som gjør akkurat det den ble laget for. Spørsmålet som er verdt å svare på, er hvilken kontekst som eier VPN-et og hvilken som eier appen du prøver å beskytte.

Ett ikon, to installasjoner, to eiere av policyen

Android gir arbeidsprofilen sin egen administrerte kontekst, komplett med separate apper, kontoer og policy, slik at launcheren kan vise to oppføringer som deler navn og merke. En VPN-tjeneste som startes inne i én kontekst, arbeider for brukerne av den konteksten, og det er mekanismen bak hele problemet. Ikonet forteller deg hvilken app du trykket på, ikke hvilken profil trafikken som følger hører til. Derfor må eieren leses fra profilen og ikke fra bildet.

En organisasjon kan også håndheve always-on eller blokker-uten-VPN for den administrerte siden, noe som endrer hva som skjer når tunnelen er nede. Den personlige siden har ingen slik garanti med mindre du har bygget en selv.

Hva en liste over tillatte apper faktisk betyr

Androids støtte for appbasert VPN er bygget rundt lister, dokumentert i veiledningen om VPN-brukere og arbeidsprofiler og de to listetypene har motsatte standardverdier. En liste over tillatte apper betyr at bare de navngitte pakkene bruker tunnelen og alt annet er utelukket, mens en liste over ikke-tillatte apper betyr at alt er inkludert unntatt de navngitte pakkene. Får du dette bakvendt, har du bygget det motsatte av den tiltenkte policyen mens innstillingsskjermen fortsatt ser rimelig ut. Listen vurderes i konteksten der VPN-et kjører, så et pakkenavn som finnes i begge profiler, matcher bare kopien i den konteksten. En pakke som ikke står på listen i den andre profilen, angår rett og slett ikke dette VPN-et.

Skriv ned oppførselen for de to eller tre appene som betyr noe, fordi forskjellen mellom alt-unntatt og bare-disse avgjør om en personlig app lekker rundt tunnelen eller feiler lukket. En liten tabell slår et avsnitt her: én rad per profil, med listetype og standarden for alt annet.

Hvilken side som kjører tunnelen, og under hvis policy

Et forbruker-VPN opphever ikke organisasjonens kontroller i den administrerte profilen, og et arbeidsprofil-VPN er ikke en generell tunnel for personlige apper. Hvis organisasjonen krever sin egen klient for administrerte apper, er den personlige klienten en separat ordning med egen policy og egne feilmoduser. Bestem hvilken mekanisme som skal bære hvilken trafikk før du sammenligner resultater, ellers måler du to systemer og kaller forskjellen en feil. Innenfor sin egen kontekst vinner den administrerte siden vanligvis, og det er den tiltenkte oppførselen.

Det vanskelige tilfellet er en administrert app som trenger en rute som den administrerte policyen ikke tilbyr. Det er en unntaksforespørsel til organisasjonen, ikke en grunn til å slå av arbeidsprofilen.

Test instansen du faktisk mente

Start kopien du bryr deg om og undersøk forespørselen innenfra, fordi en sjekk av den offentlige adressen i den personlige nettleseren ikke sier noe om arbeidsappen. Kontroller den innloggede kontoen og den interne navneoppløsningen separat, siden et internt navn kan avhenge av den administrerte ruten mens offentlig surfing blir et annet sted. Noter hvilken kopi som ga hvilket resultat i det øyeblikket du tester, og sett profilen i etiketten; et skjermbilde med to identiske ikoner er ikke bevis. Gjenta kontrollen etter en ny tilkobling og etter at profilen er gjenskapt, fordi policyen kan bli brukt på nytt imellom.

Hvis du ikke kan avgjøre hvilken kopi som svarte, fiks merkingen før du trekker noen konklusjon. Et tvetydig resultat er verre enn ingen resultat, fordi det senere blir sitert som om det avgjorde spørsmålet.

Dokumenter dekningen så neste test overlever

Noter tre fakta sammen for hver kontekst: appinstansen, policyeieren og den forventede dekningen. Det er nok for neste person til å gjenskape testen din uten å gjette hvilket ikon de startet. Legg til listetypen og standarden for pakker som ikke står på listen, fordi det er den delen folk oftest leser feil.

Kontroller deretter ett internt navn og én ekstern adresse fra hver side, og skriv ned hva som skal skje når den administrerte siden blokkerer det personlige VPN-et. En telefon der ingen av sidene er dekket mens begge ser tilkoblet ut, er feilen det er verdt å designe mot. Når begge profilene virkelig trenger en tunnel, planlegg to ordninger i stedet for én smart regel.