Como verificar o estado da VPN sem ping no Android, iOS e Windows

Fazer ping a 192.0.2.10 só lhe diz que um endereço respondeu a um eco ICMP, e nada mais. Numa rede sem túnel pode mesmo assim ter sucesso, porque o endereço pode estar na sub-rede local; com um túnel saudável pode falhar, porque o servidor descarta ICMP enquanto serve HTTPS. A verificação de que o seu script precisa é uma consulta de estado da plataforma mais um teste de rota para o destino que a aplicação usa. Trate-os como dois campos separados, nunca como um único booleano.

O que uma resposta de eco realmente prova

O ICMP é um protocolo de alcançabilidade que não tem noção de interfaces nem de túneis. Quando chega uma resposta, o kernel relata que um host respondeu; não relata qual rota levou o pedido nem qual levou a resposta. A filtragem torna o sinal ainda mais ruidoso, porque uma firewall que bloqueia pedidos de eco nada diz sobre as portas por trás dela. E um perfil de túnel dividido pode excluir de propósito o endereço testado enquanto todos os outros destinos funcionam.

O que realmente quer saber é se um serviço específico é utilizável pelo caminho que a aplicação percorre. Escolha o host e a porta que a aplicação chama e depois exija uma resposta na camada de aplicação.

Alcançabilidade e estado do túnel são factos diferentes, e qualquer um pode ser verdadeiro enquanto o outro é falso. Mantê-los separados diz-lhe a quem pertence a falha. Juntá-los numa só verificação produz um ticket que ninguém consegue encaminhar.

Pergunte ao Android pelo transporte, não por um ping

O Android responde diretamente à pergunta de estado através do ConnectivityManager. As capacidades da rede ativa transportam um indicador de transporte VPN, definido quando o tráfego é encaminhado por uma interface VPN. A chamada é local, barata e independente de qualquer host remoto responder.

Esta versão Java devolve false em vez de lançar uma exceção quando não existe rede ativa. Como lê a rede ativa, reflete o perfil que o utilizador escolheu nas Definições.

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

Para notificações de alteração, registe um NetworkCallback em vez de fazer polling com um temporizador. Não confunda isto com o VpnService.prepare, que só indica se o utilizador concedeu permissão para uma VPN, não se os pacotes estão a fluir. A revogação chega através do VpnService.onRevoke, mas esquecer um perfil nas Definições não produz qualquer difusão.

iOS: os nomes de interface são uma heurística, não um contrato

Muitos excertos de iOS inspecionam as definições de proxy, encontram o dicionário __SCOPED__ e procuram chaves de interface como tap, tun, utun2, ppp ou ipsec. Essa abordagem é uma convenção de nomes, não uma garantia documentada, pelo que uma atualização do sistema que renomeie uma interface a pode quebrar. Também tende a reportar true para entradas obsoletas que sobrevivem ao túnel.

Quando a sua aplicação é dona da configuração, o NEVPNManager dá um estado real. Descreve o túnel que a sua aplicação iniciou; com uma VPN por aplicação, outras aplicações podem ficar completamente fora desse túnel.

Recarregue as preferências antes de ler o estado, porque o valor muda à medida que o túnel sobe e desce:

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

Um indicador de estado da plataforma continua a não provar que o tráfego chega ao par. É essa lacuna que o teste de rota cobre, e é por isso que um único booleano não basta para o suporte.

Os perfis do Windows expõem um campo de estado real

O Windows acompanha os perfis VPN separadamente dos adaptadores, e o Get-VpnConnection expõe um ConnectionStatus para cada perfil que conhece. Os perfis criados através do cliente Windows ou de um pacote de aprovisionamento aparecem aqui. O cmdlet não é um detetor genérico de túneis.

Leia o campo para um perfil com nome, acrescentando -AllUserConnection quando o perfil pertence a todos os utilizadores:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

Os clientes de terceiros ficam muitas vezes invisíveis para este cmdlet mesmo com o túnel ativo, por isso um resultado vazio significa desconhecido, não desligado. As listas de adaptadores enganam da mesma forma: um adaptador do fabricante pode persistir enquanto está inativo, e alguns adaptadores só existem durante uma sessão. Para um perfil que o Windows detém, o rasdial reporta um código de saída sobre o qual pode ramificar. Tudo isto descreve uma crença local, não a alcançabilidade do par.

Estado mais rota: a verificação em duas partes

Um perfil ligado nada diz sobre para onde vão os pacotes. O túnel dividido pode manter o túnel ativo ao excluir o destino que lhe importa. Os perfis always-on ficam ligados com um servidor morto, e um kill switch bloqueia o tráfego de propósito quando o túnel cai.

Teste ambas as camadas: confirme que um transporte VPN ou um perfil está ativo e depois confirme que o destino resolve e responde por esse caminho. Em Linux, pergunte ao kernel que interface usaria:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Quando o cliente está fora do seu controlo, registe ambos os resultados e deixe o padrão apontar a camada. Ligado mais um teste de rota falhado sugere túnel dividido, DNS ou política. Desligado mais um teste de rota a funcionar significa que outro caminho está a transportar o tráfego.

Um teste que pode executar por ordem

Registe primeiro o estado da plataforma, antes de alterar qualquer estado de rede. Resolva o nome do host e anote a família de endereços, porque um registo AAAA pode seguir um caminho diferente de um registo A. Abra a porta do serviço e exija uma resposta de aplicação em vez de um simples aperto de mão. Guarde cada observação no seu próprio campo de registo.

Numa máquina Linux com dig e curl, três comandos cobrem a resolução, a rota e o próprio serviço. Execute-os com o túnel ativo e novamente com ele desligado:

dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health

Quatro campos separados batem um booleano, porque estado, DNS, rota e política falham de forma independente e acabam em equipas diferentes. Um ping no terminal continua a ser uma boa verificação manual. É uma má definição de conetividade para automação, onde a API da plataforma e um teste de rota respondem à pergunta real.