Âmbito do reset de VPN no Android: o que cada camada realmente apaga

O Android tem quatro operações separadas que as pessoas chamam de reset de VPN, e apagam coisas diferentes. Limpar a cache de uma aplicação remove ficheiros temporários; limpar o seu armazenamento remove o próprio perfil. Um reset de rede reconstrói a pilha de conectividade, e um reset de fábrica substitui a partição de dados do utilizador. Escolha a operação pelo estado que suspeita, não por hábito. Se adivinhar mal, o perfil ou o caminho de inscrição de que precisava já não existe antes de ter diagnosticado nada.

Esta é a regra que uso em cada chamada: nomeie o estado, nomeie o seu proprietário e depois remova apenas a cópia desse proprietário. O resto desta página trata de que componente do Android guarda que bytes.

Onde vive realmente um perfil de VPN no Android

Um cliente de terceiros num telefone não gerido guarda o perfil no seu próprio diretório de dados da aplicação, como ficheiro de preferências, bloco JSON ou uma pequena base de dados SQLite. É esse diretório que a opção Limpar armazenamento das Definições apaga. O perfil não está na lista de VPN do sistema: essa lista guarda o registo de ligação que o cliente registou através do VpnService, e inclui o nome da ligação, o pacote proprietário e qualquer indicador de sempre ativo definido pelo utilizador.

O VpnService é canalização, não armazenamento. O cliente pede consentimento uma vez, constrói uma interface tun e move os pacotes ele próprio, por isso a plataforma nunca precisa de compreender o formato do perfil. É por isso que um ficheiro de configuração copiado de outro telefone muitas vezes é importado como perfil vazio ou falha a validação.

As credenciais seguem outro caminho. Uma chave ou certificado obtido através do KeyChain do sistema permanece num armazém gerido pelo sistema, por isso apagar os dados da aplicação pode deixar a credencial utilizável e remover apenas o alias do cliente para ela.

Os dispositivos geridos acrescentam um segundo proprietário. Um perfil de trabalho criado por um EMM executa a sua própria cópia do cliente sob a sua própria política, e uma VPN de sempre ativo pode ser fixada pela política do dispositivo para que o utilizador não a possa desligar. Nesses dispositivos o perfil é normalmente fornecido na inscrição e não escrito à mão. A recuperação é então uma decisão de reinscrição, não de reimportação.

Cache, armazenamento, reset de rede, reset de fábrica

As quatro operações correspondem a estes limites. Leia a linha do estado que suspeita antes de tocar em qualquer coisa.

Limpar a cache é o mais seguro e o menos útil. Remove ficheiros temporários, que é também onde um cliente pode ter colocado o registo que um agente de suporte acabou de lhe pedir. O guia de resolução de problemas de aplicações do Android trata a cache e o armazenamento como duas eliminações diferentes, e você também deve fazê-lo.

Limpar armazenamento é o verdadeiro reset por aplicação. Remove o perfil, o gateway guardado e os indicadores de confiança que o cliente mantinha para redes específicas. Não revoga entradas do KeyChain, não remove um registo de VPN do sistema propriedade de outra aplicação e, num perfil gerido, não remove a política que empurrou o perfil em primeiro lugar.

O reset de rede das Definições é para todo o dispositivo, e o seu âmbito exato muda com o fabricante e a versão do Android. A caixa de confirmação da sua compilação é a única declaração fiável do que vai esquecer.

Anote primeiro o caminho de volta

Antes de qualquer passo destrutivo, anote cinco coisas: versão do cliente, nome do perfil, endereço do gateway, proprietário do serviço e a etapa exata em que a ligação falha.

São esses cinco factos que separam uma falha do cliente de uma falha de política ou de servidor. Um tempo limite, uma rejeição de certificado e uma recusa imediata são três falhas diferentes, e cada uma aponta para um proprietário diferente. Apague primeiro o armazenamento e perde a evidência do lado do cliente que as teria distinguido. Guarde uma cópia saneada do registo enquanto ele ainda existir.

Depois confirme como a ligação seria recriada. Um nome de apresentação e um nome de anfitrião não bastam quando o perfil dependia de um certificado de cliente, de uma configuração gerida ou de uma inscrição MFA vinculada a este dispositivo.

O bloqueio de arranque que ninguém planeia

Um modo de falha merece a sua própria secção. Se o único local para descarregar o perfil for um portal interno alcançável apenas através do túnel que está prestes a remover, apagar o armazenamento cria um beco sem saída dentro da aplicação.

Uma VPN de sempre ativo com a opção de bloquear ligações sem VPN transforma isso numa queda total: o telefone não tem nenhuma rota funcional para o portal e o cliente não tem nenhum perfil para levantar o túnel. Os dois estados mantêm-se um ao outro no lugar.

A saída é procedimental, não técnica. Exporte ou fotografe a configuração enquanto o túnel ainda funciona, confirme que o portal tem uma rota que não depende da VPN e só então apague algo. Num dispositivo gerido, pergunte ao administrador que caminho de recuperação existe antes de tocar no perfil.

Verifique o túnel reconstruído

Quando o perfil voltar, teste por ordem: resolução de nomes, uma ligação TCP a um anfitrião interno conhecido e o comportamento de bloqueio em caso de falha com que realmente conta. A ordem importa porque um túnel pode subir e ainda assim fugar DNS.

Um ícone de chave na barra de estado prova que a interface existe, nada mais.

Se a ligação continuar a falhar após um reset dirigido, pare de aumentar o tamanho da operação. Guarde a evidência de antes e depois, anote que camada apagou e entregue o caso ao proprietário do componente com esses cinco factos. Um reset de fábrica é uma decisão separada com um custo muito mais alto, e não é o passo seguinte de uma lista de verificação de VPN.