Perché una VPN per app manca la copia di lavoro di un’app Android
Un profilo di lavoro è un contesto gestito separato, quindi una VPN per app in un profilo può lasciare intatta la copia personale. Controlla il proprietario prima di testare.
Una stessa app compare due volte su un telefono con un profilo di lavoro, e le due copie non sono lo stesso soggetto. Una VPN per app configurata dentro un contesto governa l’istanza di quel contesto, ed è per questo che una regola che nomina il pacchetto può comunque lasciare intatta l’altra copia. Non è un difetto da aggirare, è il confine del profilo che fa esattamente ciò per cui è stato progettato. La domanda a cui vale la pena rispondere è quale contesto possiede la VPN e quale possiede l’app che stai cercando di proteggere.
Un’icona, due installazioni, due proprietari della policy
Android assegna al profilo di lavoro un proprio contesto gestito, completo di app, account e policy separati, così il launcher può mostrare due voci che condividono un nome e un badge. Un servizio VPN avviato dentro un contesto opera per gli utenti di quel contesto, ed è il meccanismo dietro l’intero problema. L’icona dice quale app hai toccato, non a quale profilo appartiene il traffico che ne deriva. Per questo il proprietario va letto dal profilo e non dall’immagine.
Un’organizzazione può anche imporre un comportamento sempre attivo o bloccante senza VPN per il lato gestito, il che cambia ciò che accade quando il tunnel è inattivo. Il lato personale non ha alcuna garanzia del genere, a meno che tu non ne abbia costruita una da solo.
Che cosa significa davvero un elenco di app consentite
Il supporto VPN per app di Android si basa su elenchi, documentati nella guida sugli utenti VPN e i profili di lavoro e i due tipi di elenco hanno valori predefiniti opposti. Un elenco di app consentite significa che solo i pacchetti nominati usano il tunnel e tutto il resto è escluso, mentre un elenco di app non consentite significa che tutto è incluso tranne i pacchetti nominati. Se lo inverti, hai costruito l’opposto della policy voluta mentre la schermata delle impostazioni sembra ancora plausibile. L’elenco viene valutato nel contesto in cui gira la VPN, quindi un nome di pacchetto presente in entrambi i profili corrisponde solo alla copia in quel contesto. Un pacchetto non elencato nell’altro profilo semplicemente non riguarda questa VPN.
Scrivi il comportamento per le due o tre app che contano, perché la differenza tra tutto-tranne e solo-queste decide se un’app personale perde traffico attorno al tunnel o fallisce in modo chiuso. Una piccola tabella batte un paragrafo qui: una riga per profilo, con il tipo di elenco e il valore predefinito per tutto il resto.
| Context | List type | Apps not named |
|---|---|---|
| Work profile | allowed only | excluded from the tunnel |
| Personal profile | disallowed | included in the tunnel |
Quale lato gestisce il tunnel, e sotto quale policy
Una VPN consumer non rimuove i controlli dell’organizzazione dal profilo gestito, e una VPN di profilo di lavoro non è un tunnel generale per le app personali. Se l’organizzazione richiede il proprio client per le app gestite, il client personale è un accordo separato con la propria policy e i propri modi di guastarsi. Decidi quale meccanismo deve trasportare quale traffico prima di confrontare i risultati, altrimenti stai misurando due sistemi e chiamando la differenza un difetto. Dentro il proprio contesto il lato gestito di solito vince, e questo è il comportamento voluto.
Il caso scomodo è un’app gestita che ha bisogno di una rotta che la policy gestita non fornisce. È una richiesta di eccezione all’organizzazione, non un motivo per disattivare il profilo di lavoro.
Testare l’istanza che intendevi davvero
Avvia la copia che ti interessa e ispeziona la richiesta dall’interno, perché un controllo dell’indirizzo pubblico nel browser personale non dice nulla sull’app di lavoro. Verifica separatamente l’account connesso e la risoluzione dei nomi interna, dato che un nome interno può dipendere dalla rotta gestita mentre la navigazione pubblica resta altrove. Annota quale copia ha prodotto quale risultato nel momento del test, e metti il profilo nell’etichetta; uno screenshot con due icone identiche non è una prova. Ripeti il controllo dopo una riconnessione e dopo la ricreazione del profilo, perché la policy può essere riapplicata nel frattempo.
Se non riesci a dire quale copia ha risposto, correggi l’etichettatura prima di trarre qualsiasi conclusione. Un risultato ambiguo è peggio di nessun risultato, perché verrà citato più tardi come se avesse risolto la questione.
Documentare la copertura perché il prossimo test sopravviva
Registra tre fatti insieme per ogni contesto: l’istanza dell’app, il proprietario della policy e la copertura attesa. Bastano alla persona successiva per riprodurre il tuo test senza indovinare quale icona ha avviato. Aggiungi il tipo di elenco e il valore predefinito per i pacchetti non elencati, perché è la parte che le persone leggono più spesso male.
Poi verifica un nome interno e un indirizzo esterno da ciascun lato, e scrivi cosa dovrebbe succedere quando il lato gestito blocca la VPN personale. Un telefono in cui nessuno dei due lati è coperto mentre entrambi sembrano connessi è il guasto contro cui vale la pena progettare. Quando entrambi i profili hanno davvero bisogno di un tunnel, pianifica due accordi invece di una regola furba.