Come leggere lo stato di VPN e proxy di un'app di lavoro gestita

Un'app di lavoro fallisce su un telefono gestito, qualcuno controlla l'interruttore VPN, lo vede attivo e dichiara il percorso sano. È qui che si fermano la maggior parte di queste diagnosi, ed è troppo presto: un trasporto VPN attivo non dice che le richieste di questa app lo abbiano usato, e il proxy che si applica davvero può essere per app o scelto da un file PAC invece di comparire nelle Impostazioni. Parti dall'app e dal profilo specifici che stai esaminando, poi leggi la visione che la piattaforma ha del percorso.

Parti dall'app e dal suo profilo

Un'app con badge di lavoro di solito gira in un profilo separato con la propria politica di rete. Un browser personale sullo stesso telefono non è una prova per lei, e non lo è nemmeno un risultato dal dispositivo di un collega con una gestione diversa. Annota a quale profilo appartiene l'app prima di leggere qualsiasi cosa.

Nelle Impostazioni, elenca le voci VPN configurate e annota a chi appartiene ciascuna. Nelle build Samsung le etichette dei menu si spostano tra le versioni, quindi descrivi la voce invece del percorso per arrivarci. Una voce in grigio o gestita appartiene a chi amministra il dispositivo; disattivarla come esperimento cambia ciò che stai cercando di misurare e può essere contrario alla politica.

Leggi lo stato che la piattaforma riporta

Dentro un'attività esistente nei tuoi strumenti di supporto, su API 23 o successiva, lo stato della rete si può leggere senza inviare un byte. La chiamata richiede il normale permesso di manifest ACCESS_NETWORK_STATE per la lettura delle capacità.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Ogni valore risponde a una domanda stretta. La rete attiva è la rete predefinita del processo chiamante in quel momento. Il controllo delle capacità ti dice se quella rete predefinita è supportata da VPN. La chiamata al proxy riporta il proxy HTTP predefinito effettivo, e l'oggetto restituito può descrivere sia un proxy statico sia uno script PAC.

Se ti serve la vista per rete invece di quella predefinita, leggi le proprietà di collegamento della stessa rete e confrontale con cm.getLinkProperties(network)?.httpProxy. Un proxy installato dalla gestione del dispositivo compare nella chiamata al proxy predefinito e non nelle proprietà di collegamento, il che è un modo rapido per distinguere un proxy fornito dalla politica da uno assegnato dalla rete.

Tieni l'output nel tuo canale di supporto invece che in un report pubblico. I nomi host del proxy, gli URL PAC e i suffissi interni rivelano come la tua organizzazione instrada il traffico, e nessuno di essi serve a descrivere il guasto.

Interpreta ogni campo in modo stretto

Una rete nulla o un oggetto capacità nullo significa che lo stato di rete del chiamante non era disponibile o è cambiato durante la lettura. Non significa che non ci sia una VPN. Trattalo come sconosciuto e rileggi dopo che l'app è passata in primo piano, non come un risultato negativo.

Un trasporto VPN è il più debole dei positivi. Qualsiasi app che detenga un VpnService ne produce uno, compresa un'app di filtraggio locale che non invia mai il tuo traffico da nessuna parte. Quindi un valore true dice che esiste una rete predefinita supportata da VPN, non che sia stata usata l'uscita della tua organizzazione e certamente non che ci sia stata un'ispezione.

Un proxy predefinito nullo significa che questa API non riporta alcun proxy HTTP predefinito per la configurazione effettiva. Esclude molto poco: un'app può portare la propria impostazione SOCKS, implementare il proprio client HTTP o essere guidata da un proxy sul gateway che il dispositivo non conosce mai.

PAC è il caso che sconfigge una risposta a valore singolo. Uno script può instradare una destinazione attraverso un proxy e inviarne un'altra diretta, quindi due richieste della stessa app entro un secondo possono prendere percorsi diversi. E un'app che lega i suoi socket a una rete scelta, o chiama bindProcessToNetwork, non è affatto obbligata a seguire il valore predefinito.

Cosa questa istantanea non può dirti

Non è una cronologia. Nulla qui registra quale percorso ha preso la richiesta che fallisce, e una lettura riuscita dopo il guasto non è una prova sul guasto. Non è nemmeno un inventario: ottieni la rete predefinita del processo chiamante, non un elenco delle connessioni private di ogni app.

Non dice nulla nemmeno su ciò che accade sopra il socket. Una stretta di mano TLS che fallisce su un dispositivo gestito può essere un problema dell'archivio di fiducia, una discrepanza di pinning o un nome che il proxy rifiuta, e nessuno di questi compare in una lettura di connettività.

Ecco perché le due metà contano insieme: l'istantanea restringe dove guardare, e la diagnostica dell'app dice che cosa è fallito davvero.

Riportalo in una forma che un amministratore possa usare

Indica l'app interessata, il profilo, il timestamp e la fase esatta che è fallita: risoluzione dei nomi, connessione TCP, stretta di mano TLS o uno stato HTTP. Aggiungi i valori dell'istantanea così come sono stati letti, con i null scritti come null e non come nessuno. Annota se altre app nello stesso profilo falliscono allo stesso modo, il che separa un problema dell'app da un problema di percorso sull'intero profilo.

Poi fermati e lascia rispondere il proprietario del percorso. Non trattare un certificato aziendale, un indirizzo proxy o una voce VPN come autorizzazione a rimuovere la gestione o aggirare il percorso approvato; questo trasforma un caso di supporto in un incidente di politica.

Il contratto del proxy predefinito è breve e vale una lettura, perché definisce esattamente quale proxy la chiamata riporta, e ogni lettura eccessiva di questa istantanea inizia assumendo che riporti di più.