Per què una VPN per aplicació no arriba a la còpia de feina d’una app d’Android

Una mateixa aplicació apareix dos cops en un telèfon amb perfil de feina, i les dues còpies no són el mateix subjecte. Una VPN per aplicació configurada dins d’un context governa la instància d’aquell context, i per això una regla que anomena el paquet pot deixar intacta l’altra còpia. No és un defecte que calgui esquivar, és la frontera del perfil fent exactament allò per a què es va dissenyar. La pregunta que val la pena respondre és quin context posseeix la VPN i quin posseeix l’aplicació que intentes protegir.

Una icona, dues instal·lacions, dos propietaris de la política

Android dona al perfil de feina el seu propi context gestionat, amb aplicacions, comptes i política separats, de manera que el llançador pot mostrar dues entrades que comparteixen nom i insígnia. Un servei de VPN iniciat dins d’un context opera per als usuaris d’aquell context, i aquest és el mecanisme que hi ha darrere de tot el problema. La icona et diu quina aplicació has tocat, no a quin perfil pertany el trànsit que se’n deriva. Per això el propietari s’ha de llegir del perfil i no de la imatge.

Una organització també pot imposar un comportament sempre actiu o de bloqueig sense VPN al costat gestionat, cosa que canvia què passa quan el túnel està caigut. El costat personal no té aquesta garantia, tret que te n’hagis construït una tu mateix.

Què significa realment una llista d’aplicacions permeses

El suport de VPN per aplicació d’Android es basa en llistes, documentat a la guia sobre usuaris de VPN i perfils de feina i els dos tipus de llista tenen valors per defecte oposats. Una llista d’aplicacions permeses significa que només els paquets anomenats fan servir el túnel i tota la resta queda exclosa, mentre que una llista d’aplicacions no permeses significa que tot hi és inclòs excepte els paquets anomenats. Si ho inverteixes, hauràs construït el contrari de la política volguda mentre la pantalla de configuració encara sembla plausible. La llista s’avalua dins del context on s’executa la VPN, així que un nom de paquet present en tots dos perfils només coincideix amb la còpia d’aquell context. Un paquet no llistat a l’altre perfil simplement no és assumpte d’aquesta VPN.

Escriu el comportament per a les dues o tres aplicacions que importen, perquè la diferència entre tot-excepte i només-aquestes decideix si una aplicació personal es filtra voltant del túnel o falla de manera tancada. Una taula petita guanya un paràgraf aquí: una fila per perfil, amb el tipus de llista i el valor per defecte per a tota la resta.

Quin costat executa el túnel, i sota quina política

Una VPN de consum no aixeca els controls de l’organització del perfil gestionat, i una VPN de perfil de feina no és un túnel general per a aplicacions personals. Si l’organització exigeix el seu propi client per a les aplicacions gestionades, el client personal és un acord a part amb la seva pròpia política i les seves pròpies maneres de fallar. Decideix quin mecanisme ha de transportar quin trànsit abans de comparar resultats, o estaràs mesurant dos sistemes i anomenant la diferència un defecte. Dins del seu propi context, el costat gestionat sol guanyar, i aquest és el comportament previst.

El cas incòmode és una aplicació gestionada que necessita una ruta que la política gestionada no proporciona. Això és una sol·licitud d’excepció a l’organització, no un motiu per desactivar el perfil de feina.

Provar la instància que realment volies

Obre la còpia que t’importa i inspecciona la sol·licitud des de dins, perquè una comprovació de l’adreça pública al navegador personal no diu res sobre l’aplicació de feina. Verifica per separat el compte connectat i la resolució de noms interna, ja que un nom intern pot dependre de la ruta gestionada mentre la navegació pública es queda en un altre lloc. Anota quina còpia va produir quin resultat en el moment de la prova, i posa el perfil a l’etiqueta; una captura amb dues icones idèntiques no és una prova. Repeteix la comprovació després d’una reconnexió i després que el perfil es torni a crear, perquè la política es pot tornar a aplicar entremig.

Si no pots dir quina còpia ha respost, arregla l’etiquetatge abans de treure cap conclusió. Un resultat ambigu és pitjor que cap resultat, perquè més tard es cita com si hagués resolt la qüestió.

Documentar la cobertura perquè la propera prova sobrevisqui

Registra tres fets junts per a cada context: la instància de l’aplicació, el propietari de la política i la cobertura esperada. Això n’hi ha prou perquè la propera persona reprodueixi la teva prova sense endevinar quina icona va obrir. Afegeix el tipus de llista i el valor per defecte per als paquets no llistats, perquè és la part que la gent llegeix més sovint malament.

Després verifica un nom intern i una adreça externa de cada costat, i anota què hauria de passar quan el costat gestionat bloquegi la VPN personal. Un telèfon on cap dels dos costats no està cobert mentre tots dos semblen connectats és la fallada contra la qual val la pena dissenyar. Quan els dos perfils realment necessitin un túnel, planifica dos acords en lloc d’una regla enginyosa.