L’app di lavoro richiede una VPN? Controllate prima questi tre livelli

Il messaggio dice che l’app ha bisogno di una VPN, ma di solito l’app segnala un sintomo invece di nominare ciò che l’ha bloccata. Tre responsabili distinti possono produrre quella frase: il servizio privato con cui parla l’app, il codice di policy dell’app stessa e il livello di gestione del dispositivo che controlla il profilo di lavoro. Quale dei tre sta chiedendo cambia ciò che dovreste fare, e solo uno dei tre si risolve collegando un tunnel. Trovare prima il responsabile vi risparmia di reinstallare un client che non è mai stato il problema.

Cosa può verificare l’app stessa

Prima di ipotizzare una regola nascosta della piattaforma, ricordate che un’app normale può vedere se un trasporto VPN è attivo. ConnectivityManager segnala le reti che portano TRANSPORT_VPN, e l’assenza di NET_CAPABILITY_NOT_VPN dice a qualsiasi chiamante che il percorso attuale passa per un tunnel. Uno sviluppatore che vuole rifiutarsi di funzionare fuori da un tunnel può farlo con API pubbliche e senza alcuno strumento aziendale.

Ciò che l’app non può vedere in questo modo è di chi sia la VPN. Un flag di trasporto dice che esiste un tunnel, non che termina dove la vostra organizzazione si aspetta.

Il percorso del servizio: nomi e indirizzi privati

La versione onesta più comune del messaggio non è affatto un controllo di policy. L’app risolve un nome host interno, come un wiki o un endpoint API che esiste solo nella vista DNS aziendale, e la ricerca fallisce prima che venga eseguito qualsiasi codice di policy. Il tunnel può essere attivo e far passare traffico internet generale mentre il DNS diviso invia quel nome a un resolver che non ne ha mai sentito parlare.

I sintomi qui sono ristretti. Un host fallisce, le altre chiamate di rete dell’app funzionano, e il guasto compare durante una ricerca di nome anziché all’avvio. I certificati interni aggiungono un secondo modo di guasto, perché un’app fissata alla CA dell’organizzazione rifiuta un certificato pubblico anche quando i pacchetti fluiscono.

Collegare una VPN commerciale qualsiasi non risolve nulla di tutto ciò. Cambia il vostro indirizzo di uscita e lascia il nome interno ugualmente irrisolvibile.

Il livello di policy dell’app

Un’app può anche portare il proprio cancello. Le configurazioni gestite consentono all’organizzazione di inviare coppie chiave-valore che l’app dichiara, e l’app le legge tramite RestrictionManager. Una chiave come un nome di profilo richiesto o un elenco di reti consentite è interamente design dello sviluppatore, applicato nel codice dell’app con il testo di errore che quel codice sceglie.

È questo il livello in cui la formulazione di solito tradisce la causa. Se il messaggio appare subito all’avvio, prima di qualsiasi chiamata di rete, e menziona una policy, un profilo o un amministratore, probabilmente state guardando la logica dell’app e non un pacchetto perso.

Leggere la stessa restrizione su un dispositivo personale è un vicolo cieco. I dispositivi non gestiti non hanno restrizioni da leggere, quindi l’app ricade sul valore predefinito con cui è stata costruita.

Il livello della piattaforma: sempre attivo e blocco

La gestione del dispositivo aggiunge un’imposizione che l’app non può aggirare. Un controller di policy del dispositivo può chiamare setAlwaysOnVpnPackage per il profilo di lavoro, eventualmente con il blocco attivo, e una volta attivo il blocco la piattaforma rifiuta il traffico che non passa per quel pacchetto. Il blocco è visibile come condizione di sistema e non come errore dell’app: anche le altre app del profilo smettono di raggiungere la rete.

La portata conta. La VPN sempre attiva si configura per utente, quindi un pacchetto del profilo di lavoro non copre il vostro profilo personale, e una VPN personale non soddisfa il pacchetto del profilo di lavoro. Due profili, due policy di rete indipendenti, un dispositivo.

È anche l’unico livello in cui una VPN estranea non può aiutare, perché la policy nomina un pacchetto specifico.

Distinguere i tre

Percorrete le firme in ordine e fermatevi alla prima che corrisponde. Un nome host che fallisce mentre tutto il resto si risolve indica il percorso del servizio. Un rifiuto immediato all’avvio con formulazione di policy indica la logica dell’app. Un intero profilo che perde la connettività ogni volta che il client approvato si disconnette indica il blocco. E un’app che accetta qualsiasi tunnel sta controllando il flag di trasporto, non l’identità della vostra organizzazione.

Prove utili: il testo esatto e il suo momento, se altre app dello stesso profilo hanno ancora connettività, se il nome privato si risolve dentro il tunnel approvato e se il dispositivo mostra un badge di lavoro per l’app che avete aperto.

Cosa mettere nella richiesta di supporto

Una richiesta che nomina il livello viene instradata correttamente al primo tentativo. Qualcosa come: l’app del profilo di lavoro si apre, l’elenco delle risorse fallisce dopo la connessione della VPN approvata, la risoluzione del nome privato fallisce nella diagnostica consentita, e le altre app del profilo continuano a funzionare. Questo si legge come un problema di rotta o di resolver e salta il ciclo di reimpostazione dell’account.

Se la VPN approvata manca del tutto, la via supportata è l’iscrizione o il riprovisioning tramite il vostro amministratore. Rimuovere il profilo di gestione, installare un client estraneo o falsificare lo stato della rete cambia l’assetto di sicurezza invece di ripristinarlo.

Partite dal livello, non dal client. Le tre firme qui sopra di solito risolvono la questione in una sola sessione.