Android 12 e IKEv1 VPN: versión de lanzamento, IKEv2 e aplicacións de terceiros

Dous teléfonos mostran Android 12 en Axustes, e só un deles segue iniciando o perfil IPsec XAuth antigo que ofrece a súa pasarela. A diferenza non é un axuste ao que o usuario poida chegar: a garda que controla a ruta nativa IKEv1 mira o nivel de SDK co que se enviou o dispositivo, non só a versión que executa agora. Ese único detalle decide se unha comparación de flotas ten sentido, e tamén decide cal das tres rutas de migración necesita de verdade.

Dous teléfonos Android 12 non son o mesmo caso de proba

O cambio de AOSP que impediu que os dispositivos novos iniciasen perfís IKEv1 antigos compara DEVICE_INITIAL_SDK_INT con Android S, é dicir, API 31. Na ruta de arranque nativa, un perfil válido provoca un fallo de operación non admitida antes de que exista calquera conexión útil. Un teléfono enviado con Android 11 e actualizado despois segue pasando esa garda; un modelo lanzado con Android 12 non.

Pode ler os dous números nun dispositivo coa 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

O primeiro valor é o nivel de lanzamento que lle importa á garda; o segundo é o que executa hoxe o teléfono. Cando falta a propiedade, apóiase na documentación de soporte do modelo en lugar de adiviñar polo nome comercial, e non supoña que a compilación do fabricante conserva todas as rutas de compatibilidade da súa versión base.

Outra distinción aforra unha hora de soporte perdida: un perfil gardado que segue nos axustes de VPN non demostra nada sobre se a plataforma o iniciará. Volver introducir a PSK ou editar rutas non pode eliminar unha comprobación de soporte de protocolo que se executa antes, e o fallo parece un problema de credenciais cando non o é.

Ruta un: manter a pila nativa onde aínda funciona

A pila antiga é a que le perfís IPsec XAuth PSK, IPsec Hybrid RSA e L2TP/IPsec PSK da pantalla de VPN do sistema. Nun dispositivo enviado por baixo de API 31 segue sendo unha ruta viable tras unha actualización, por iso un piloto nun teléfono antigo pode funcionar mentres un novo non inicia o mesmo perfil.

A comparación que importa é por clase de dispositivo, non por versión de Android: enumere os modelos da flota, lea os seus niveis de API de lanzamento e divídaos entre dispositivos que aínda inician o perfil e dispositivos que non poden. Calquera outra cousa produce unha política de soporte que se contradí no momento en que un usuario compra un teléfono novo.

Ruta dous: perfís IKEv2 de plataforma

O modelo público de aprovisionamento de Android para IKEv2 é outro obxecto, non un perfil IKEv1 renomeado. A API de plataforma para perfís IKEv2 chegou con API 30 e espera IKEv2 co método de autenticación que ofrece a pasarela, normalmente baseado en certificado ou EAP. Non hai actualización compatible por cable de IKEv1 XAuth ou Hybrid a IKEv2: a pasarela debe configurarse para o novo protocolo e o perfil debe levar a identidade correspondente.

É a ruta con máis vida e tamén a que expón o traballo real. A validación de identidade, a autenticación de usuario, o DNS, as rutas de túnel dividido e a autorización de recursos deben sobrevivir á migración; conseguir que só o aperto de mans funcione deixa os usuarios conectados a un túnel que non chega a nada.

O despregamento adoita ir por MDM ou por unha configuración xestionada en lugar de que o usuario escriba campos. Se esa infraestrutura aínda non existe, o plan de migración debe incluíla, porque volver introducir un perfil IKEv2 a man en cada dispositivo non é unha operación que un servizo de asistencia poida absorber.

Ruta tres: unha aplicación cliente de terceiros

Algunhas aplicacións VPN traen a súa propia implementación do protocolo e non dependen en absoluto da pila nativa. Iso convérteas nun parche lexítimo para unha flota que non pode migrar rápido, pero a pregunta de compatibilidade pasa á aplicación: se implementa exactamente o modo IKEv1 que fala a súa pasarela, coa autenticación e os conxuntos de cifrado que esixe.

Trate a matriz de soporte da propia aplicación como a autoridade e non a descrición da tenda, e probe un dispositivo real contra a pasarela real antes de recomendala. Facer root a un teléfono para restaurar unha ruta de plataforma eliminada tampouco é unha solución mantida; traslada o problema a unha configuración non admitida que a próxima actualización do sistema pode romper en silencio.

Elixa polo que a pasarela pode ofrecer

A decisión estreitase cando sabe dúas cousas: que dispositivos se lanzaron con API 31 ou despois, e se a pasarela pode ofrecer un servizo IKEv2 co mesmo modelo de alta. Se pode, migre e deixe de investir no perfil antigo. Se aínda non pode, manteña IKEv1 para os dispositivos que aínda o inician, e dea aos dispositivos novos un cliente de terceiros como excepción documentada e limitada no tempo, non como unha solución non declarada.

Dous puntos fan defendible o plan. Primeiro, rexistre o motivo de cada excepción co modelo e o nivel de lanzamento, para que un auditor vexa que o límite é unha garda de plataforma e non unha preferencia sen explicar. Segundo, trate a migración como traballo planificado: IKEv1 está obsoleto na vía de estándares (RFC 9395), o que significa que os dispositivos restantes seguirán reducíndose e as excepcións deberían caducar con eles.