Android 12 i IKEv1 VPN: versió de llançament, IKEv2 i aplicacions de tercers

Dos telèfons mostren Android 12 a Configuració, però només un d’ells encara inicia el perfil IPsec XAuth antic que ofereix la vostra passarel·la. La diferència no és un paràmetre que l’usuari pugui tocar: la guarda que controla el camí natiu IKEv1 mira el nivell d’SDK amb què es va enviar el dispositiu, no només la versió que executa ara. Aquest sol detall decideix si una comparació de flotes té sentit, i també decideix quin dels tres camins de migració necessiteu realment.

Dos telèfons Android 12 no són el mateix cas de prova

El canvi d’AOSP que va impedir que els dispositius nous iniciessin perfils IKEv1 antics compara DEVICE_INITIAL_SDK_INT amb Android S, que és API 31. Al camí d’inici natiu, un perfil admissible provoca un error d’operació no suportada abans que existeixi cap connexió útil. Un telèfon enviat amb Android 11 i actualitzat després encara passa aquesta guarda; un model llançat amb Android 12 no.

Podeu llegir els dos números en un dispositiu amb la depuració activada:

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

El primer valor és el nivell de llançament que importa a la guarda, el segon és el que el telèfon executa avui. Quan la propietat no hi és, feu cas de la documentació de suport del model en lloc d’endevinar a partir del nom comercial, i no assumiu que la compilació del fabricant conserva tots els camins de compatibilitat de la versió base.

Una altra distinció estalvia una hora de suport malgastada: un perfil desat que encara apareix a la configuració de VPN no demostra res sobre si la plataforma l’iniciarà. Tornar a introduir la PSK o editar rutes no pot eliminar una comprovació de suport de protocol que s’executa abans, i la fallada sembla un problema de credencials quan no ho és.

Camí u: mantenir la pila nativa on encara funciona

La pila antiga és la que llegeix perfils IPsec XAuth PSK, IPsec Hybrid RSA i L2TP/IPsec PSK de la pantalla de VPN del sistema. En un dispositiu enviat per sota d’API 31 continua sent un camí viable després d’una actualització, per això un pilot en un telèfon més antic pot funcionar mentre un de nou falla amb el mateix perfil.

La comparació que importa és per classe de dispositiu, no per versió d’Android: llisteu els models de la flota, llegiu-ne els nivells d’API de llançament i separeu-los entre dispositius que encara inicien el perfil i dispositius que no poden. Qualsevol altra cosa produeix una política de suport que es contradiu en el moment que un usuari compra un telèfon nou.

Camí dos: perfils IKEv2 de plataforma

El model públic de proveïment d’Android per a IKEv2 és un objecte diferent, no un perfil IKEv1 rebatejat. L’API de plataforma per als perfils IKEv2 va arribar amb API 30 i espera IKEv2 amb el mètode d’autenticació que ofereix la passarel·la, normalment basat en certificat o EAP. No hi ha cap actualització compatible per cable d’IKEv1 XAuth o Hybrid a IKEv2: la passarel·la s’ha de configurar per al protocol nou i el perfil ha de portar la identitat corresponent.

Aquest és el camí amb més vida, i també el que exposa la feina real. La validació d’identitat, l’autenticació d’usuari, el DNS, les rutes de túnel dividit i l’autorització de recursos han de sobreviure a la migració; fer que només l’encaixada de mans funcioni deixa els usuaris connectats a un túnel que no arriba enlloc.

El desplegament sol passar per MDM o per una configuració gestionada en lloc que l’usuari escrigui camps. Si aquesta infraestructura encara no existeix, el pla de migració l’ha d’incloure, perquè tornar a introduir un perfil IKEv2 a mà a cada dispositiu no és una operació que un servei d’assistència pugui absorbir.

Camí tres: una aplicació client de tercers

Algunes aplicacions VPN porten la seva pròpia implementació del protocol i no depenen gens de la pila nativa. Això les fa un pedaç legítim per a una flota que no pot migrar de pressa, però la pregunta de compatibilitat passa a l’aplicació: si implementa exactament el mode IKEv1 que parla la vostra passarel·la, amb l’autenticació i els conjunts de xifratge que exigeix.

Tracteu la matriu de suport de l’aplicació com l’autoritat i no la descripció de la botiga, i proveu un dispositiu real contra la passarel·la real abans de recomanar-la. Fer root a un telèfon per restaurar un camí de plataforma eliminat tampoc no és una solució mantinguda; trasllada el problema a una configuració no suportada que la propera actualització del sistema pot trencar silenciosament.

Trieu segons el que la passarel·la pot oferir

La decisió s’estreny quan sabeu dues coses: quins dispositius es van llançar amb API 31 o després, i si la passarel·la pot oferir un servei IKEv2 amb el mateix model d’alta. Si pot, migreu i deixeu d’invertir en el perfil antic. Si encara no pot, manteniu IKEv1 per als dispositius que encara l’inicien, i doneu als dispositius nous un client de tercers com a excepció documentada i limitada en el temps, no com una solució no declarada.

Dues coses fan el pla defensable. Primer, registreu el motiu de cada excepció amb el model i el nivell de llançament, perquè un auditor vegi que el límit és una guarda de plataforma i no una preferència sense explicar. Segon, tracteu la migració com a feina planificada: IKEv1 està descontinuat a la via d’estàndards (RFC 9395), cosa que vol dir que els dispositius restants continuaran reduint-se i les excepcions haurien de caducar amb ells.