I profili IKEv2 VPN di Android sono per utente, non per dispositivo

L’espressione VPN integrata su Android copre due cose non collegate: un’implementazione di protocollo che la piattaforma esegue per voi e la forma delle impostazioni che il produttore ha scelto di esporre. Non sono lo stesso oggetto e nessuna delle due garantisce che il tunnel appartenga all’utente le cui applicazioni ne hanno bisogno. Il provisioning avviene in un utente preciso con un pacchetto chiamante preciso, e tutto ciò che segue eredita quel contesto. Leggete la catena di proprietà prima della schermata delle impostazioni.

Cosa costruisce la piattaforma per voi

Da Android 11 la piattaforma espone il provisioning VPN tramite VpnManager. Un’applicazione approvata descrive un profilo IKEv2 e la piattaforma esegue essa stessa lo scambio IPsec e IKE, così l’applicazione non tocca mai i pacchetti. È la differenza sostanziale rispetto a un’applicazione VPN propria, che implementa VpnService e costruisce il tunnel nel proprio processo.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

La chiamata qui sopra è uno schizzo della forma, non un blocco da copiare: il builder ha diverse varianti di autenticazione, differiscono per livello di API e il profilo porta anche il materiale di fiducia del certificato del server. Per la questione della proprietà conta qualcosa di più stretto della sintassi.

Da questo progetto derivano due proprietà. Il profilo è un dato, quindi un amministratore può predisporlo invece di digitarlo a mano. E il tunnel è una rete della piattaforma, quindi le applicazioni lo vedono come una rete con trasporto VPN e non come il socket di un’altra applicazione.

La proprietà è l’utente, poi il pacchetto

Il multiutente di Android è separazione reale, non un’etichetta. Un profilo di lavoro è un utente separato con i suoi pacchetti installati, i suoi dati delle applicazioni, il suo archivio delle chiavi e le sue ancore di fiducia. Lo stesso prodotto installato in entrambi i posti sono due istanze con identificatori utente diversi, anche quando icone e nomi coincidono.

Il provisioning viene registrato sul pacchetto chiamante in quell’utente. Perciò un’applicazione di provisioning nel profilo personale crea un tunnel personale, e le applicazioni di lavoro del profilo di lavoro non ne vedono nulla. Vale anche il contrario, ed è per questo che un tunnel del profilo di lavoro è invisibile alle applicazioni personali senza una politica esplicita che dica il contrario.

Un controller di criteri del dispositivo può predisporre per conto di un profilo gestito, il che spiega la voce che nessuno in ufficio ricorda di aver creato. Se state verificando un telefono, quello è il probabile proprietario di un profilo in grigio, e non tocca a voi cancellarlo come esperimento.

Tre porte prima che un pacchetto si muova

La prima porta è l’autorità: la gestione deve permettere una VPN, e alcune distribuzioni limitano il tipo oltre all’esistenza. La seconda è l’identità: il certificato client o le credenziali devono essere disponibili nell’utente che possiede il profilo, perché un certificato importato nell’archivio personale non è visibile al profilo di lavoro.

La terza è il consenso e la politica. L’utente di solito approva la connessione al primo uso, e un amministratore può inoltre fissarla come sempre attiva, eventualmente con blocco perché il traffico non esca dal tunnel. Quelle impostazioni decidono cosa succede quando il tunnel cade, ed è la parte che gli utenti notano.

L’ambito è il punto in cui le tre si incontrano. Il profilo determina il gateway e l’identità, mentre lo strato di criteri decide quali applicazioni possono usare il tunnel e se il traffico vi è forzato. Per questo due telefoni con indirizzi di gateway identici possono comportarsi in modo molto diverso.

Perché una connessione personale non copre le applicazioni di lavoro

Il traffico di un’applicazione di lavoro nasce nell’utente di lavoro, e la politica di rete applicabile è quella di quell’utente. Un tunnel stabilito nel profilo personale non lo trasporta, per quanto sano sembri l’indicatore. Questo solo fatto spiega la maggior parte delle segnalazioni in cui l’utente giura che la VPN è connessa e un’applicazione specifica non raggiunge comunque un servizio interno.

La risoluzione dei nomi segue lo stesso confine. I suffissi DNS privati e le ancore di fiducia sono per utente, quindi un nome host interno che si risolve nel profilo personale può fallire in quello di lavoro anche con un tunnel dall’aspetto equivalente, perché la politica del resolver e l’archivio CA sono oggetti diversi.

Verificate su un’iscrizione reale, non su un telefono da laboratorio

Sul dispositivo, identificate prima il proprietario della voce: quale utente, quale pacchetto e se il profilo proviene dal provisioning della piattaforma o da un’applicazione con un proprio servizio VPN. Poi confermate che l’identità attesa dal profilo sia davvero presente nell’archivio delle chiavi di quell’utente.

Provate il ciclo di vita, non solo la connessione. Accedete, sbloccate l’archivio delle credenziali, lasciate che il profilo di lavoro si fermi per la sera, riportatelo e verificate che il tunnel torni senza un tocco manuale. Un profilo di lavoro che si spegne fuori orario porta con sé il tunnel, ed è un comportamento atteso e non un guasto, purché lo stato di indisponibilità atteso sia documentato.

Infine provate l’applicazione di lavoro stessa contro un endpoint interno noto e confrontatelo con il risultato del profilo personale. I due possono differire; ciò che non può differire è il modello di proprietà. Se il tunnel appartiene all’utente sbagliato, nessuna riemissione di certificati lo sistemerà.

Non forzate la questione avviando attività di impostazioni nascoste per rivelare un menu, e non copiate chiavi private tra profili per far comparire una connessione. Il riferimento VpnManager documenta cosa può predisporre chi chiama; se il percorso approvato non include il vostro caso, è una decisione dell’amministratore e non un problema di impostazioni.