Como comprobar o estado da VPN sen ping en Android, iOS e Windows

Un ping só demostra que un equipo respondeu, non que a túnel estea activa. Consulta as API de estado de Android, iOS e Windows e despois verifica a ruta que a túa aplicación realmente necesita.

Facer ping a 192.0.2.10 só che di que un enderezo respondeu a un eco ICMP, e nada máis. Nunha rede sen túnel pode funcionar igualmente, porque o enderezo pode estar na subrede local; cun túnel san pode fallar, porque o servidor descarta ICMP mentres serve HTTPS. A comprobación que necesita o teu script é unha consulta de estado da plataforma máis unha proba de ruta cara ao destino que usa a aplicación. Trátaas como dous campos separados, nunca como un único booleano.

Que demostra realmente unha resposta de eco

ICMP é un protocolo de alcanzabilidade que non ten noción de interfaces nin de túneis. Cando chega unha resposta, o núcleo informa de que un equipo respondeu; non informa da ruta que levou a petición nin da que levou a resposta. O filtrado fai o sinal aínda máis ruidoso, xa que unha devasa que bloquea solicitudes de eco non di nada sobre os portos que hai detrás. E un perfil de túnel dividido pode excluír a propósito o enderezo probado mentres todos os demais destinos funcionan.

O que realmente queres saber é se un servizo concreto é utilizable pola ruta que toma a aplicación. Escolle o equipo e o porto aos que chama a aplicación e despois esixe unha resposta na capa de aplicación.

A alcanzabilidade e o estado do túnel son feitos distintos, e calquera deles pode ser certo mentres o outro é falso. Mantelos separados diche a quen pertence o fallo. Xuntalos nunha soa comprobación produce un ticket que ninguén pode encamiñar.

Píde lle a Android o transporte, non un ping

Android responde directamente á pregunta de estado mediante ConnectivityManager. As capacidades da rede activa levan un indicador de transporte VPN, definido cando o tráfico se encamiña por unha interface VPN. A chamada é local, barata e independente de que responda algún equipo remoto.

Esta versión Java devolve false en vez de lanzar unha excepción cando non hai rede activa. Como le a rede activa, reflicte o perfil que o usuario escolleu nos Axustes.

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

Para as notificacións de cambio, rexistra un NetworkCallback en lugar de sondar cun temporizador. Non confundas iso con VpnService.prepare, que só informa de se o usuario concedeu permiso para unha VPN, non de se os paquetes están fluíndo. A revogación chega por VpnService.onRevoke, pero esquecer un perfil nos Axustes non produce ningunha difusión.

iOS: os nomes de interface son unha heurística, non un contrato

Moitos fragmentos de iOS inspeccionan a configuración do proxy, atopan o dicionario __SCOPED__ e buscan claves de interface como tap, tun, utun2, ppp ou ipsec. Ese enfoque é unha convención de nomes, non unha garantía documentada, así que unha actualización do sistema que renomee unha interface pode rompelo. Tamén tende a informar de true para entradas obsoletas que sobreviven ao túnel.

Cando a túa aplicación posúe a configuración, NEVPNManager dáche un estado real. Describe o túnel que iniciou a túa aplicación; cunha VPN por aplicación, outras aplicacións poden quedar totalmente fóra dese túnel.

Recarga as preferencias antes de ler o estado, xa que o valor cambia a medida que o túnel sobe e baixa:

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

Un indicador de estado da plataforma tampouco demostra que o tráfico chegue ao par. Ese oco é o que cobre a proba de ruta, e por iso un só booleano non abonda para o soporte.

Os perfís de Windows expoñen un campo de estado real

Windows rastrexa os perfís VPN por separado dos adaptadores, e Get-VpnConnection expón un ConnectionStatus para cada perfil que coñece. Aquí aparecen os perfís creados co cliente de Windows ou cun paquete de aprovisionamento. O cmdlet non é un detector xeral de túneis.

Le o campo para un perfil con nome, engadindo -AllUserConnection cando o perfil pertence a todos os usuarios:

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

Os clientes de terceiros adoitan quedar invisibles para este cmdlet mesmo co túnel activo, así que un resultado baleiro significa descoñecido, non desconnectado. As listas de adaptadores enganan igual: un adaptador de fabricante pode persistir mentres está inactivo, e algúns adaptadores só existen durante unha sesión. Para un perfil que Windows posúe, rasdial informa dun código de saída sobre o que podes ramificar. Todo isto describe unha crenza local, non a alcanzabilidade do par.

Estado máis ruta: a comprobación en dúas partes

Un perfil conectado non di nada sobre a onde van os paquetes. O túnel dividido pode manter o túnel activo mentres exclúe o destino que che importa. Os perfís always-on quedan conectados cun servidor morto, e un kill switch bloquea o tráfico a propósito cando cae o túnel.

Proba as dúas capas: confirma que hai un transporte VPN ou un perfil activo e despois confirma que o destino resolve e responde por esa ruta. En Linux, pregunta ao núcleo que interface usaría:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Cando o cliente está fóra do teu control, rexistra ambos os resultados e deixa que o patrón sinale a capa. Conectado máis unha proba de ruta fallida suxire túnel dividido, DNS ou política. Desconectado máis unha proba de ruta correcta significa que outra ruta leva o tráfico.

Unha proba que podes executar por orde

Rexistra primeiro o estado da plataforma, antes de cambiar calquera estado de rede. Resolve o nome de equipo e anota a familia de enderezos, xa que un rexistro AAAA pode tomar unha ruta distinta dun rexistro A. Abre o porto do servizo e esixe unha resposta de aplicación en vez dun simple apretón de mans. Mantén cada observación no seu propio campo de rexistro.

Nunha máquina Linux con dig e curl, tres comandos cobren a resolución, a ruta e o propio servizo. Execútaos co túnel activo e de novo con el caído:

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

Catro campos separados baten un booleano, porque o estado, o DNS, a ruta e a política fallan de forma independente e acaban en equipos distintos. Un ping de terminal segue sendo unha boa comprobación manual. É unha mala definición de conectividade para a automatización, onde a API da plataforma e unha proba de ruta responden á pregunta real.

Artigos relacionados