Android 12 e IKEv1 VPN: versione di fornitura, IKEv2 e app di terze parti

Due telefoni mostrano entrambi Android 12 nelle Impostazioni, e solo uno di essi avvia ancora il vecchio profilo IPsec XAuth offerto dal gateway. La differenza non è un’impostazione raggiungibile dall’utente: la guardia che controlla il percorso nativo IKEv1 guarda il livello SDK con cui il dispositivo è stato fornito, non solo la versione in esecuzione ora. Quel singolo dettaglio decide se un confronto di flotta ha senso, e decide anche quale dei tre percorsi di migrazione vi serve davvero.

Due telefoni Android 12 non sono lo stesso caso di test

La modifica di AOSP che ha impedito ai nuovi dispositivi di avviare i vecchi profili IKEv1 confronta DEVICE_INITIAL_SDK_INT con Android S, cioè API 31. Sul percorso di avvio nativo, un profilo idoneo genera un errore di operazione non supportata prima che esista qualsiasi connessione utile. Un telefono fornito con Android 11 e poi aggiornato supera ancora quella guardia; un modello lanciato con Android 12 no.

Potete leggere i due numeri su un dispositivo con il debug attivo:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

Il primo valore è il livello di fornitura a cui guarda la guardia, il secondo è ciò che il telefono esegue oggi. Quando la proprietà manca, basatevi sulla documentazione di supporto del modello invece di indovinare dal nome commerciale, e non date per scontato che la build del produttore conservi tutti i percorsi di compatibilità della versione base.

Un’altra distinzione risparmia un’ora di supporto sprecata: un profilo salvato ancora elencato nelle impostazioni VPN non dimostra nulla su se la piattaforma lo avvierà. Reinserire la PSK o modificare le rotte non può rimuovere un controllo di supporto del protocollo eseguito prima, e l’errore sembra un problema di credenziali quando non lo è.

Percorso uno: mantenere lo stack vecchio dove funziona ancora

Lo stack vecchio è quello che legge i profili IPsec XAuth PSK, IPsec Hybrid RSA e L2TP/IPsec PSK dalla schermata VPN di sistema. Su un dispositivo fornito sotto API 31 resta un percorso praticabile dopo un aggiornamento, per questo un pilota su un telefono più vecchio può riuscire mentre uno nuovo non avvia lo stesso profilo.

Il confronto che conta è per classe di dispositivo, non per versione di Android: elencate i modelli della flotta, leggete i loro livelli API di fornitura e divideteli tra dispositivi che avviano ancora il profilo e dispositivi che non possono. Qualsiasi altra cosa produce una politica di supporto che si contraddice nel momento in cui un utente compra un telefono nuovo.

Percorso due: profili IKEv2 della piattaforma

Il modello pubblico di provisioning di Android per IKEv2 è un altro oggetto, non un profilo IKEv1 rinominato. L’API di piattaforma per i profili IKEv2 è arrivata con API 30 e si aspetta IKEv2 con il metodo di autenticazione offerto dal gateway, di solito basato su certificato o EAP. Non esiste un aggiornamento compatibile a livello di filo da IKEv1 XAuth o Hybrid a IKEv2: il gateway deve essere configurato per il nuovo protocollo e il profilo deve portare l’identità corrispondente.

È il percorso con la vita più lunga, e anche quello che rivela il lavoro vero. Validazione dell’identità, autenticazione utente, DNS, rotte del tunnel diviso e autorizzazione delle risorse devono tutte sopravvivere alla migrazione; far riuscire solo la stretta di mano lascia gli utenti collegati a un tunnel che non raggiunge nulla.

La distribuzione di solito passa da un MDM o da una configurazione gestita invece che dalla digitazione di campi da parte dell’utente. Se quell’infrastruttura non esiste ancora, il piano di migrazione deve includerla, perché reinserire a mano un profilo IKEv2 su ogni dispositivo non è un’operazione che un help desk possa assorbire.

Percorso tre: un’app client di terze parti

Alcune app VPN portano la propria implementazione del protocollo e non dipendono affatto dallo stack nativo. Questo le rende una soluzione temporanea legittima per una flotta che non può migrare in fretta, ma la domanda di compatibilità si sposta sull’app: se implementa esattamente la modalità IKEv1 che parla il vostro gateway, con l’autenticazione e le suite di cifratura che il gateway richiede.

Trattate la matrice di supporto dell’app come l’autorità e non la descrizione dello store, e testate un dispositivo reale contro il gateway reale prima di consigliarla. Fare root a un telefono per ripristinare un percorso di piattaforma rimosso non è nemmeno una soluzione mantenuta; sposta il problema in una configurazione non supportata che il prossimo aggiornamento di sistema può rompere in silenzio.

Scegliete in base a ciò che il gateway può offrire

La decisione si restringe quando sapete due cose: quali dispositivi sono stati lanciati con API 31 o successiva, e se il gateway può offrire un servizio IKEv2 con lo stesso modello di registrazione. Se può, migrate e smettete di investire nel vecchio profilo. Se non può ancora, mantenete IKEv1 per i dispositivi che lo avviano ancora, e date ai nuovi dispositivi un client di terze parti come eccezione documentata e limitata nel tempo, non come aggiramento non dichiarato.

Due punti rendono il piano difendibile. Primo, registrate il motivo di ogni eccezione insieme al modello e al livello di fornitura, così un revisore vede che il confine è una guardia di piattaforma e non una preferenza inspiegata. Secondo, trattate la migrazione come lavoro pianificato: IKEv1 è deprecato nel percorso degli standard (RFC 9395), il che significa che i dispositivi rimanenti continueranno a ridursi e le eccezioni dovrebbero scadere con loro.