Android 12 e IKEv1 VPN: versão de lançamento, IKEv2 e apps de terceiros

Dois telefones mostram Android 12 nas Configurações, e apenas um deles ainda inicia o antigo perfil IPsec XAuth que o seu gateway oferece. A diferença não é uma configuração que o usuário alcance: a proteção que barra o caminho legado nativo de IKEv1 olha o nível de SDK com que o aparelho foi lançado, não apenas a versão que ele executa agora. Esse único detalhe decide se uma comparação de frota faz sentido, e também decide qual dos três caminhos de migração você realmente precisa.

Dois telefones com Android 12 não são o mesmo caso de teste

A mudança no AOSP que impediu aparelhos novos de iniciarem perfis IKEv1 legados compara DEVICE_INITIAL_SDK_INT com Android S, que é API 31. No caminho legado nativo de inicialização, um perfil qualificado gera uma falha de operação não suportada antes de existir qualquer conexão útil. Um telefone lançado com Android 11 e atualizado depois ainda passa por essa proteção; um modelo lançado com Android 12 não passa.

Você pode ler os dois números em um aparelho com depuração ativada:

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 nível de lançamento que interessa à proteção, o segundo é o que o telefone executa hoje. Onde a propriedade não existe, apoie-se na documentação de suporte do modelo em vez de adivinhar pelo nome de marketing, e não presuma que uma compilação do fabricante preserve todo caminho de compatibilidade da versão base.

Mais uma distinção economiza uma hora de suporte desperdiçada: um perfil salvo ainda listado nas configurações de VPN não prova nada sobre se a plataforma vai iniciá-lo. Reintroduzir a PSK ou editar rotas não remove uma verificação de suporte de protocolo que roda antes, e a falha parece um problema de credenciais quando não é.

Caminho um: manter a pilha legada nativa onde ela ainda roda

A pilha legada é a que lê perfis IPsec XAuth PSK, IPsec Hybrid RSA e L2TP/IPsec PSK na tela de VPN do sistema. Em um aparelho lançado abaixo da API 31, ela continua um caminho viável após a atualização, e é por isso que um piloto em um aparelho antigo pode dar certo enquanto um aparelho novo falha no mesmo perfil.

A comparação que importa é por classe de aparelho, não por versão do Android: liste os modelos da frota, leia os níveis de API de lançamento e divida entre aparelhos que ainda iniciam o perfil e aparelhos que não conseguem. Qualquer outra coisa produz uma política de suporte que se contradiz no momento em que o usuário compra um telefone novo.

Caminho dois: perfis IKEv2 da plataforma

O modelo público de provisionamento do Android para IKEv2 é outro objeto, não um perfil IKEv1 renomeado. A API de plataforma para perfis IKEv2 chegou com a API 30 e espera IKEv2 com o método de autenticação que o gateway oferece, normalmente baseado em certificado ou EAP. Não há atualização compatível no fio de IKEv1 XAuth ou Hybrid para IKEv2: o gateway precisa ser configurado para o novo protocolo, e o perfil precisa carregar a identidade correspondente.

Este é o caminho de vida mais longa e também o que expõe o trabalho real. Validação de identidade, autenticação de usuário, DNS, rotas de túnel dividido e autorização de recursos precisam todos sobreviver à migração; fazer apenas o handshake funcionar deixa usuários conectados a um túnel que não alcança nada.

A implantação costuma passar por um MDM ou configuração gerenciada, e não por um usuário digitando campos. Se essa infraestrutura ainda não existe, o plano de migração precisa incluí-la, porque reentrar um perfil IKEv2 à mão em cada aparelho não é uma operação que um help desk absorva.

Caminho três: um aplicativo cliente de terceiros

Alguns aplicativos de VPN trazem a própria implementação de protocolo e não dependem da pilha legada nativa. Isso os torna um paliativo legítimo para uma frota que não consegue migrar rápido, mas a questão de compatibilidade passa para o aplicativo: se ele implementa exatamente o modo IKEv1 que o seu gateway fala, com a autenticação e os conjuntos de cifras que o gateway exige.

Trate a matriz de suporte do próprio aplicativo como autoridade, e não a descrição da loja, e teste um aparelho real contra o gateway real antes de recomendá-lo. Rootear um telefone para restaurar um caminho de plataforma removido também não é solução mantida; move o problema para uma configuração sem suporte que a próxima atualização do sistema pode quebrar em silêncio.

Escolha pelo que o gateway pode oferecer

A decisão estreita quando você sabe duas coisas: quais aparelhos foram lançados na API 31 ou depois, e se o gateway consegue apresentar um serviço IKEv2 com o mesmo modelo de registro. Se consegue, migre e pare de investir no perfil legado. Se ainda não consegue, mantenha IKEv1 para os aparelhos que ainda o iniciam, e dê aos aparelhos novos um cliente de terceiros como exceção documentada e com prazo, em vez de um contorno não declarado.

Dois pontos tornam o plano defensável. Primeiro, registre o motivo de cada exceção com o modelo e o nível de lançamento, para que um auditor veja que a fronteira é uma proteção da plataforma e não uma preferência inexplicada. Segundo, trate a migração como trabalho planejado: IKEv1 está obsoleto na trilha de padrões (RFC 9395), o que significa que os aparelhos restantes vão continuar encolhendo e as exceções devem expirar com eles.