Los perfiles IKEv2 VPN de Android son por usuario, no por dispositivo

La expresión VPN integrada cubre en Android dos cosas sin relación: una implementación de protocolo que la plataforma ejecuta por usted y la forma de ajustes que el fabricante decidió exponer. No son el mismo objeto y ninguna garantiza que el túnel pertenezca al usuario cuyas aplicaciones lo necesitan. El aprovisionamiento ocurre en un usuario concreto con un paquete que llama concreto, y todo lo demás hereda ese contexto. Lea la cadena de propiedad antes de la pantalla de ajustes.

Qué construye la plataforma por usted

Desde Android 11 la plataforma expone el aprovisionamiento de VPN mediante VpnManager. Una aplicación aprobada describe un perfil IKEv2 y la plataforma ejecuta ella misma el intercambio IPsec e IKE, así que la aplicación nunca toca paquetes. Esa es la diferencia sustancial con una aplicación VPN propia, que implementa VpnService y construye el túnel en su proceso.

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

La llamada de arriba es un esbozo de la forma, no un bloque para copiar: el constructor tiene varias variantes de autenticación, difieren según el nivel de API y el perfil también lleva el material de confianza del certificado del servidor. Para la cuestión de la propiedad importa algo más estrecho que la sintaxis.

De este diseño se siguen dos propiedades. El perfil son datos, así que un administrador puede aprovisionarlo en lugar de escribirlo a mano. Y el túnel es una red de la plataforma, así que las aplicaciones lo ven como una red con transporte VPN y no como el socket de otra aplicación.

La propiedad es el usuario y después el paquete

El multiusuario de Android es separación real, no una etiqueta. Un perfil de trabajo es un usuario aparte con sus paquetes instalados, sus datos de aplicaciones, su almacén de claves y sus anclas de confianza. El mismo producto instalado en ambos sitios son dos instancias con identificadores de usuario distintos, aunque los iconos y los nombres sean idénticos.

El aprovisionamiento se registra contra el paquete que llama en ese usuario. Por eso una aplicación de aprovisionamiento en el perfil personal crea un túnel personal, y las aplicaciones de trabajo del perfil de trabajo no ven nada de él. Lo contrario también es cierto, y por eso un túnel del perfil de trabajo es invisible para las aplicaciones personales sin una política explícita que diga lo contrario.

Un controlador de políticas del dispositivo puede aprovisionar en nombre de un perfil gestionado, lo que explica la entrada que nadie en la oficina recuerda haber creado. Si audita un teléfono, ese es el propietario probable de un perfil atenuado, y no es cosa suya borrarlo como experimento.

Tres puertas antes de que se mueva un paquete

La primera puerta es la autoridad: la gestión debe permitir una VPN, y algunos despliegues restringen el tipo además de la existencia. La segunda es la identidad: el certificado de cliente o las credenciales deben estar disponibles en el usuario dueño del perfil, porque un certificado importado en el almacén personal no es visible para el perfil de trabajo.

La tercera es el consentimiento y la política. El usuario suele aprobar la conexión la primera vez que se usa, y un administrador puede además fijarla como siempre activa, opcionalmente con bloqueo para que el tráfico no salga fuera del túnel. Esos ajustes deciden qué pasa cuando el túnel cae, y es la parte que la gente nota.

El alcance es donde se encuentran las tres. El perfil determina la puerta de enlace y la identidad, mientras que la capa de política decide qué aplicaciones pueden usar el túnel y si el tráfico se fuerza por él. Por eso dos teléfonos con direcciones de puerta idénticas pueden comportarse de forma muy distinta.

Por qué una conexión personal no cubre las aplicaciones de trabajo

El tráfico de una aplicación de trabajo se genera en el usuario de trabajo, y la política de red aplicable es la de ese usuario. Un túnel establecido en el perfil personal no lo transporta, por sano que parezca el indicador. Ese solo hecho explica la mayoría de los informes en los que el usuario jura que la VPN está conectada y una aplicación concreta sigue sin alcanzar un servicio interno.

La resolución de nombres sigue la misma frontera. Los sufijos DNS privados y las anclas de confianza son por usuario, así que un nombre interno que resuelve en el perfil personal puede fallar en el de trabajo incluso con un túnel de aspecto equivalente, porque la política del resolutor y el almacén de CA son objetos distintos.

Verifique en una inscripción real, no en un teléfono de laboratorio

En el dispositivo, identifique primero al dueño de la entrada: qué usuario, qué paquete y si el perfil vino del aprovisionador de la plataforma o de una aplicación con su propio servicio VPN. Después confirme que la identidad que espera el perfil está realmente en el almacén de claves de ese usuario.

Pruebe el ciclo de vida, no solo la conexión. Inicie sesión, desbloquee el almacén de credenciales, deje que el perfil de trabajo pause por la noche, tráigalo de vuelta y compruebe que el túnel vuelve sin un toque manual. Un perfil de trabajo que se apaga fuera de horario se lleva su túnel, y eso es comportamiento esperado y no una avería, siempre que el estado no disponible esperado esté escrito.

Por último, pruebe la propia aplicación de trabajo contra un extremo interno conocido y compárelo con el resultado del perfil personal. Se permite que difieran; lo que no puede diferir es el modelo de propiedad. Si el túnel pertenece al usuario equivocado, ninguna reemisión de certificados lo arreglará.

No fuerce el asunto lanzando actividades de ajustes ocultas para revelar un menú, y no copie claves privadas entre perfiles para hacer aparecer una conexión. La referencia de VpnManager documenta qué puede aprovisionar quien llama; si la vía aprobada no incluye su caso, eso es decisión del administrador y no un problema de ajustes.