Perfis de VPN IKEv2 no Android são por usuário, não por dispositivo
O túnel é provisionado por usuário e por pacote chamador, então uma entrada no telefone pode ser a errada. Verifique a propriedade antes das configurações.
A expressão VPN embutida cobre duas coisas sem relação no Android: uma implementação de protocolo que a plataforma executa em seu nome e a forma de configuração que o fabricante decidiu expor. Não são o mesmo objeto, e nenhuma das duas garante que o túnel pertença ao usuário cujos aplicativos precisam dele. O provisionamento ocorre em um usuário específico com um pacote chamador específico, e tudo o que vem depois herda esse contexto. Leia a cadeia de propriedade antes de ler a tela de configurações.
O que a plataforma constrói para você
Desde o Android 11 a plataforma expõe o provisionamento de VPN por meio de VpnManager. Um aplicativo aprovado descreve um perfil IKEv2, e a plataforma executa a troca IPsec e IKE por conta própria, então o aplicativo nunca toca nos pacotes. Essa é a diferença relevante em relação a um aplicativo de VPN próprio, que implementa VpnService e constrói o túnel no seu próprio processo.
val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
.setAuthUsernamePassword(user, secret, rootCa)
.build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)A chamada acima é um esboço da forma e não um bloco para copiar e colar: o builder tem várias sobrecargas de autenticação, elas variam conforme o nível de API, e o perfil também carrega o material de confiança do certificado do servidor. O que importa para a questão da propriedade é mais estreito que a sintaxe.
Duas propriedades decorrem desse desenho. O perfil é dado, então pode ser provisionado por um administrador em vez de digitado à mão. E o túnel é uma rede da plataforma, então aparece aos aplicativos como uma rede com transporte VPN e não como o socket de outro aplicativo.
A propriedade é do usuário, depois do pacote
O multiusuário do Android é separação real, não um rótulo. Um perfil de trabalho é um usuário separado, com seus próprios pacotes instalados, seus próprios dados de aplicativos, seu próprio keystore e suas próprias âncoras de confiança. O mesmo produto instalado nos dois lugares são duas instâncias com identificadores de usuário diferentes, mesmo quando os ícones do lançador e os nomes dos produtos são idênticos.
O provisionamento é registrado contra o pacote chamador naquele usuário. Assim, um aplicativo de provisionamento em execução no perfil pessoal cria um túnel pessoal, e os aplicativos de trabalho no perfil de trabalho não veem nada dele. O inverso também é verdadeiro, e é por isso que um túnel de perfil de trabalho é invisível aos aplicativos pessoais sem uma política explícita que diga o contrário.
Um controlador de política de dispositivo pode provisionar em nome de um perfil gerenciado, e isso explica a entrada que ninguém no escritório lembra de ter criado. Se você está auditando um telefone, esse é o provável dono de um perfil acinzentado, e não cabe a você excluí-lo como experimento.
Três portões antes de um pacote se mover
O primeiro portão é a autoridade: a gestão precisa permitir VPN, e algumas implantações restringem também o tipo, além da existência. O segundo é a identidade: o certificado de cliente ou as credenciais precisam estar disponíveis no usuário que possui o perfil, porque um certificado importado no keystore pessoal não é visível ao perfil de trabalho.
O terceiro é consentimento e política. O usuário costuma aprovar a conexão na primeira vez que ela é usada, e um administrador pode ainda fixá-la como sempre ativa, opcionalmente com bloqueio para que o tráfego não saia fora do túnel. Essas configurações decidem o que acontece quando o túnel cai, e é a parte que os usuários percebem.
O escopo é onde os três se encontram. O perfil determina o gateway e a identidade, enquanto a camada de política decide quais aplicativos podem usar o túnel e se o tráfego é forçado por ele. Dois telefones com endereços de gateway idênticos podem, portanto, se comportar de maneira muito diferente.
Por que uma conexão pessoal não cobre aplicativos de trabalho
O tráfego de um aplicativo de trabalho é gerado no usuário de trabalho, e a política de rede aplicável é a daquele usuário. Um túnel estabelecido no perfil pessoal não o transporta, por mais saudável que o indicador pareça. Esse único fato explica a maioria dos relatos em que o usuário jura que a VPN está conectada e um aplicativo específico ainda não alcança um serviço interno.
A resolução de nomes segue a mesma fronteira. Sufixos de DNS privado e âncoras de confiança são por usuário, então um nome de host interno que resolve no perfil pessoal pode falhar no perfil de trabalho mesmo com um túnel aparentemente equivalente, porque a política do resolvedor e o armazenamento de CAs são objetos diferentes.
Verifique em uma inscrição real, não em um telefone de laboratório
No dispositivo, identifique primeiro o dono da entrada: qual usuário, qual pacote e se o perfil veio do provisionador da plataforma ou de um aplicativo que implementa o próprio serviço de VPN. Depois confirme que a identidade que o perfil espera está de fato presente no keystore daquele usuário.
Teste o ciclo de vida, não só a conexão. Entre, desbloqueie o armazenamento de credenciais, deixe o perfil de trabalho pausar pela noite, traga-o de volta e verifique se o túnel retorna sem um toque manual. Um perfil de trabalho que se desliga fora do horário leva o túnel consigo, e isso é comportamento esperado, não falha, desde que o estado indisponível esperado esteja documentado.
Por fim, teste o próprio aplicativo de trabalho contra um endpoint interno conhecido e compare com o resultado do perfil pessoal. Os dois podem diferir; o que não pode diferir é o modelo de propriedade. Se o túnel pertence ao usuário errado, reemitir certificados não resolve.
Não force a situação lançando atividades ocultas de configurações para revelar um menu, e não copie chaves privadas entre perfis para fazer uma conexão aparecer. A referência do VpnManager documenta o que um chamador tem permissão para provisionar; se o caminho aprovado não inclui o seu caso, isso é uma decisão do administrador e não um problema de configurações.