Os perfís IKEv2 VPN de Android son por usuario, non por dispositivo

A expresión VPN integrada cobre en Android dúas cousas sen relación: unha implementación de protocolo que a plataforma executa por vostede e a forma de axustes que o fabricante decidiu expor. Non son o mesmo obxecto e ningunha garante que o túnel pertenza ao usuario cuxas aplicacións o necesitan. O aprovisionamento ocorre nun usuario concreto cun paquete que chama concreto, e todo o demais herda ese contexto. Lea a cadea de propiedade antes da pantalla de axustes.

Que constrúe a plataforma por vostede

Desde Android 11 a plataforma expón o aprovisionamento de VPN mediante VpnManager. Unha aplicación aprobada describe un perfil IKEv2 e a plataforma executa ela mesma o intercambio IPsec e IKE, así que a aplicación nunca toca paquetes. Esa é a diferenza substancial cunha aplicación VPN propia, que implementa VpnService e constrúe o túnel no seu proceso.

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

A chamada de arriba é un esbozo da forma, non un bloque para copiar: o construtor ten varias variantes de autenticación, difiren segundo o nivel de API e o perfil tamén leva o material de confianza do certificado do servidor. Para a cuestión da propiedade importa algo máis estreito que a sintaxe.

Deste deseño seguen dúas propiedades. O perfil son datos, así que un administrador pode aprovisionalo en lugar de escribilo a man. E o túnel é unha rede da plataforma, así que as aplicacións veno como unha rede con transporte VPN e non como o socket doutra aplicación.

A propiedade é o usuario e despois o paquete

O multiusuario de Android é separación real, non unha etiqueta. Un perfil de traballo é un usuario aparte cos seus paquetes instalados, os seus datos de aplicacións, o seu almacén de claves e as súas áncoras de confianza. O mesmo produto instalado nos dous sitios son dúas instancias con identificadores de usuario distintos, aínda que as iconas e os nomes coincidan.

O aprovisionamento rexístrase contra o paquete que chama nese usuario. Por iso unha aplicación de aprovisionamento no perfil persoal crea un túnel persoal, e as aplicacións de traballo do perfil de traballo non ven nada del. O contrario tamén é certo, e por iso un túnel do perfil de traballo é invisible para as aplicacións persoais sen unha política explícita que diga o contrario.

Un controlador de políticas do dispositivo pode aprovisionar en nome dun perfil xestionado, o que explica a entrada que ninguén na oficina recorda crear. Se audita un teléfono, ese é o propietario probable dun perfil atenuado, e non é cousa súa borralo como experimento.

Tres portas antes de que se mova un paquete

A primeira porta é a autoridade: a xestión debe permitir unha VPN, e algunhas implantacións restrinxen o tipo ademais da existencia. A segunda é a identidade: o certificado de cliente ou as credenciais deben estar dispoñibles no usuario dono do perfil, porque un certificado importado no almacén persoal non é visible para o perfil de traballo.

A terceira é o consentimento e a política. O usuario adoita aprobar a conexión no primeiro uso, e un administrador pode ademais fixala como sempre activa, opcionalmente con bloqueo para que o tráfico non saia fóra do túnel. Eses axustes deciden que pasa cando o túnel cae, e é a parte que a xente nota.

O alcance é onde se atopan as tres. O perfil determina a pasarela e a identidade, mentres que a capa de política decide que aplicacións poden usar o túnel e se o tráfico se forza por el. Por iso dous teléfonos con enderezos de pasarela idénticos poden comportarse de forma moi distinta.

Por que unha conexión persoal non cobre as aplicacións de traballo

O tráfico dunha aplicación de traballo xérase no usuario de traballo, e a política de rede aplicable é a dese usuario. Un túnel establecido no perfil persoal non o transporta, por san que pareza o indicador. Ese só feito explica a maioría dos informes nos que o usuario xura que a VPN está conectada e unha aplicación concreta segue sen alcanzar un servizo interno.

A resolución de nomes segue a mesma fronteira. Os sufixos DNS privados e as áncoras de confianza son por usuario, así que un nome interno que resolve no perfil persoal pode fallar no de traballo mesmo cun túnel de aspecto equivalente, porque a política do resolutor e o almacén de CA son obxectos distintos.

Verifique nun rexistro real, non nun teléfono de laboratorio

No dispositivo, identifique primeiro o dono da entrada: que usuario, que paquete e se o perfil veu do aprovisionador da plataforma ou dunha aplicación co seu propio servizo VPN. Despois confirme que a identidade que espera o perfil está realmente no almacén de claves dese usuario.

Probe o ciclo de vida, non só a conexión. Inicie sesión, desbloquee o almacén de credenciais, deixe que o perfil de traballo pouse pola noite, tráigao de volta e comprobe que o túnel volve sen un toque manual. Un perfil de traballo que se apaga fóra de horario leva o seu túnel, e iso é comportamento esperado e non unha avaría, sempre que o estado non dispoñible esperado estea escrito.

Por último, probe a propia aplicación de traballo contra un extremo interno coñecido e compáreo co resultado do perfil persoal. Permítese que difiran; o que non pode diferir é o modelo de propiedade. Se o túnel pertence ao usuario equivocado, ningunha reemisión de certificados o arranxará.

Non force o asunto lanzando actividades de axustes ocultas para revelar un menú, e non copie claves privadas entre perfís para facer aparecer unha conexión. A referencia de VpnManager documenta que pode aprovisionar quen chama; se a vía aprobada non inclúe o seu caso, iso é decisión do administrador e non un problema de axustes.