Android 12 e IKEv1 VPN: versión de lanzamiento, IKEv2 y apps de terceros

Dos teléfonos muestran Android 12 en Ajustes, y solo uno de ellos sigue iniciando el perfil IPsec XAuth antiguo que ofrece su puerta de enlace. La diferencia no es un ajuste al que el usuario pueda llegar: la guarda que controla la ruta nativa IKEv1 mira el nivel de SDK con el que se envió el dispositivo, no solo la versión que ejecuta ahora. Ese único detalle decide si una comparación de flotas tiene sentido, y también decide cuál de las tres rutas de migración necesita de verdad.

Dos teléfonos Android 12 no son el mismo caso de prueba

El cambio de AOSP que impidió que los dispositivos nuevos iniciaran perfiles IKEv1 antiguos compara DEVICE_INITIAL_SDK_INT con Android S, es decir, API 31. En la ruta de arranque nativa, un perfil válido provoca un fallo de operación no admitida antes de que exista cualquier conexión útil. Un teléfono enviado con Android 11 y actualizado después sigue pasando esa guarda; un modelo lanzado con Android 12 no.

Puede leer los dos números en un dispositivo con la depuración 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 es el nivel de lanzamiento que le importa a la guarda; el segundo es lo que ejecuta hoy el teléfono. Cuando la propiedad falta, apóyese en la documentación de soporte del modelo en lugar de adivinar por el nombre comercial, y no suponga que la compilación del fabricante conserva todas las rutas de compatibilidad de su versión base.

Otra distinción ahorra una hora de soporte perdida: un perfil guardado que sigue en los ajustes de VPN no demuestra nada sobre si la plataforma lo iniciará. Volver a introducir la PSK o editar rutas no puede eliminar una comprobación de soporte de protocolo que se ejecuta antes, y el fallo parece un problema de credenciales cuando no lo es.

Ruta uno: mantener la pila nativa donde aún funciona

La pila antigua es la que lee perfiles IPsec XAuth PSK, IPsec Hybrid RSA y L2TP/IPsec PSK de la pantalla de VPN del sistema. En un dispositivo enviado por debajo de API 31 sigue siendo una ruta viable tras una actualización, por eso un piloto en un teléfono antiguo puede funcionar mientras uno nuevo no inicia el mismo perfil.

La comparación que importa es por clase de dispositivo, no por versión de Android: enumere los modelos de la flota, lea sus niveles de API de lanzamiento y divídalos entre dispositivos que aún inician el perfil y dispositivos que no pueden. Cualquier otra cosa produce una política de soporte que se contradice en el momento en que un usuario compra un teléfono nuevo.

Ruta dos: perfiles IKEv2 de plataforma

El modelo público de aprovisionamiento de Android para IKEv2 es otro objeto, no un perfil IKEv1 renombrado. La API de plataforma para perfiles IKEv2 llegó con API 30 y espera IKEv2 con el método de autenticación que ofrece la puerta de enlace, normalmente basado en certificado o EAP. No hay actualización compatible por cable de IKEv1 XAuth o Hybrid a IKEv2: la puerta de enlace debe configurarse para el nuevo protocolo y el perfil debe llevar la identidad correspondiente.

Es la ruta con más vida y también la que expone el trabajo real. La validación de identidad, la autenticación de usuario, el DNS, las rutas de túnel dividido y la autorización de recursos deben sobrevivir a la migración; conseguir que solo el saludo funcione deja a los usuarios conectados a un túnel que no llega a nada.

El despliegue suele ir por MDM o por una configuración gestionada en lugar de que el usuario escriba campos. Si esa infraestructura aún no existe, el plan de migración debe incluirla, porque volver a introducir un perfil IKEv2 a mano en cada dispositivo no es una operación que un servicio de asistencia pueda absorber.

Ruta tres: una aplicación cliente de terceros

Algunas aplicaciones VPN traen su propia implementación del protocolo y no dependen en absoluto de la pila nativa. Eso las convierte en un parche legítimo para una flota que no puede migrar rápido, pero la pregunta de compatibilidad pasa a la aplicación: si implementa exactamente el modo IKEv1 que habla su puerta de enlace, con la autenticación y los conjuntos de cifrado que exige.

Trate la matriz de soporte de la propia aplicación como la autoridad y no la descripción de la tienda, y pruebe un dispositivo real contra la puerta de enlace real antes de recomendarla. Hacer root a un teléfono para restaurar una ruta de plataforma eliminada tampoco es una solución mantenida; traslada el problema a una configuración no admitida que la próxima actualización del sistema puede romper en silencio.

Elija por lo que la puerta de enlace puede ofrecer

La decisión se estrecha cuando sabe dos cosas: qué dispositivos se lanzaron con API 31 o después, y si la puerta de enlace puede ofrecer un servicio IKEv2 con el mismo modelo de alta. Si puede, migre y deje de invertir en el perfil antiguo. Si aún no puede, mantenga IKEv1 para los dispositivos que todavía lo inician, y dé a los dispositivos nuevos un cliente de terceros como excepción documentada y limitada en el tiempo, no como una solución no declarada.

Dos puntos hacen defendible el plan. Primero, registre el motivo de cada excepción con el modelo y el nivel de lanzamiento, para que un auditor vea que el límite es una guarda de plataforma y no una preferencia sin explicar. Segundo, trate la migración como trabajo planificado: IKEv1 está obsoleto en la vía de estándares (RFC 9395), lo que significa que los dispositivos restantes seguirán reduciéndose y las excepciones deberían caducar con ellos.