VPN presa em Connecting no modo avião: encontre o enlace ascendente
Um cliente que fica em Connecting no modo avião pode simplesmente não ter enlace ascendente. Separe o estado do rádio, a associação, o login no portal e a política de bloqueio.
O telemóvel mostra o ícone do avião, o cliente VPN está em Connecting há dois minutos e o perfil está correto. Há uma hora funcionava no mesmo edifício. Nada está avariado: uma VPN é uma ligação transportada por outra rede, e o modo avião acabou de remover a rede que a transportava. O cliente continua a tentar porque é o que faz sem um enlace ascendente.
O que confunde é que o símbolo do avião não diz se o Wi-Fi está disponível, e Connecting não diz se o cliente está a autenticar ou apenas à espera. Separe estas duas leituras e o diagnóstico demora um minuto.
O símbolo do avião não é um relatório de rádio
Em dispositivos Android compatíveis, o Wi-Fi e o Bluetooth podem ficar ativos no modo avião, e o dispositivo lembra-se da escolha que fez da última vez. O guia da Google sobre o modo avião no Pixel descreve exatamente esse comportamento. Portanto o ícone pode significar apenas que o celular está desligado, e nada mais.
Verifique o estado real em vez do glifo. adb shell settings get global airplane_mode_on devolve 0 ou 1 para o próprio modo, e adb shell dumpsys connectivity lista as redes que o dispositivo tem neste momento, com o respetivo estado de validação. Estas duas saídas em conjunto respondem à pergunta que o ícone não consegue.
Se o Wi-Fi estiver desligado, ou ligado mas sem associação a nada, não há caminho até ao ponto final da VPN e nenhuma quantidade de reconexões o criará. É o caso que vale a pena excluir primeiro, porque é o único em que a correção certa está fora da aplicação VPN.
O que Connecting significa realmente
Um cliente pode manter um perfil guardado, mostrar o seu nome e rodar um indicador sem ter contactado nada. A configuração é local. Estabelecer um túnel exige um servidor acessível, um handshake concluído e uma interface por onde encaminhar. Só essa última parte precisa de uma rede a funcionar, e é por isso que as duas primeiras podem parecer bem-sucedidas com o rádio desligado.
Assim, o indicador é compatível com pelo menos três situações diferentes: nenhum enlace ascendente, um enlace ascendente que não alcança o ponto final, e um enlace ascendente que o alcança mas falha a autenticação. No ecrã parecem idênticos e num registo são completamente diferentes. Por isso o primeiro artefacto útil em qualquer destes casos é o registo, não outra tentativa.
A própria documentação de VPN do Android traça a mesma fronteira entre o estabelecimento da ligação e as políticas separadas de sempre ativo e de bloqueio. É essa separação que explica porque um telemóvel pode parecer protegido estando offline e ainda assim não ter túnel.
Quatro estados que vale a pena distinguir
Os quatro estados abaixo são os que vale a pena nomear, porque o ecrã mostra-os de forma idêntica.
| State | What you will see | What to do |
|---|---|---|
| Airplane mode, Wi-Fi off | No networks in dumpsys, VPN retries forever | Turn Wi-Fi on, or accept that the tunnel cannot exist |
| Wi-Fi on, not associated | Interface exists, no default network | Join the access point |
| Associated, not validated | Network listed, captive-portal flag set | Complete the portal sign-in, then reconnect |
| Validated, tunnel down | Internet works, VPN fails or blocks | Debug the tunnel, not the radio |
A terceira linha apanha a maioria das pessoas em hotéis e aeroportos. A associação não é admissão: um portal que não deixou passar o telemóvel aceitará de bom grado a palavra-passe do Wi-Fi e depois recusará deixar passar tráfego para o ponto final da VPN. Iniciar sessão primeiro pelo navegador, com o túnel desligado, é normalmente a única forma de passar.
Porque é que o bloqueio faz parecer pior
Se a VPN sempre ativa e o bloqueio de ligações sem VPN estiverem ambos ativados, cada aplicação abrangida fica bloqueada sempre que o túnel não está levantado. Isso é a funcionalidade a funcionar, não uma segunda avaria. O sintoma passa de uma aplicação a falhar para tudo a falhar, o que se lê como um problema muito maior.
Também explica a sequência que as pessoas leem mal: modo avião ativado, sem enlace ascendente, aplicações bloqueadas, a VPN diz connecting. O bloqueio era a política a fazer o seu trabalho. Desativar a política para testar o enlace ascendente remove a proteção que provavelmente queríamos e não ensina nada.
Verifique antes o âmbito. Que aplicações estão abrangidas, quais estão excluídas e se o perfil é por utilizador ou para todo o dispositivo. Uma tarefa que inicia a aplicação VPN assim que o Wi-Fi aparece é um gatilho, não uma garantia de que nenhum pacote saiu antes de correr.
Uma ordem de diagnóstico que acaba com as suposições
Trabalhe de baixo para cima. Confirme o modo, confirme que existe uma rede, que está validada, que consegue alcançar algo fora da sub-rede local, e só então olhe para o cliente. adb shell ping -c 3 1.1.1.1 é um teste grosseiro, mas separa um caminho em falta de um caminho que existe enquanto o túnel está insatisfeito.
Se o ping falhar enquanto há uma rede listada, o problema está acima da VPN e nenhuma definição do cliente o corrige. Se o ping funcionar e o túnel ainda não se estabelecer, capture o registo do cliente nesse momento: o erro distingue um tempo esgotado de uma rejeição de autenticação, e esses dois não têm nada em comum.
Termine repondo o estado pretendido: Wi-Fi permitido no modo avião se for a sua configuração habitual, o portal concluído e a política de bloqueio de novo ativa. Depois reconecte uma vez e confirme que o túnel sobe sozinho, porque uma configuração que só funciona após tentativas manuais voltará a falhar no próximo arranque.