Com comprovar l'estat de la VPN sense ping a Android, iOS i Windows

El ping només demostra que un amfitrió ha respost, no que el túnel estigui actiu. Consulteu les API d'estat d'Android, iOS i Windows i després verifiqueu la ruta que la vostra aplicació realment necessita.

Fer ping a 192.0.2.10 només us diu que una adreça ha respost a un eco ICMP, i no us diu res més. En una xarxa sense túnel pot funcionar igualment, perquè l'adreça pot ser a la subxarxa local; amb un túnel saludable pot fallar, perquè el servidor descarta ICMP mentre serveix HTTPS. La comprovació que necessita el vostre script és una consulta d'estat de la plataforma més una prova de ruta cap a la destinació que utilitza l'aplicació. Tracteu-les com dos camps separats, mai com un sol booleà.

Què demostra realment una resposta d'eco

ICMP és un protocol d'abastabilitat que no entén d'interfícies ni de túnels. Quan arriba una resposta, el nucli informa que un amfitrió ha respost; no informa quina ruta ha portat la petició ni quina ha portat la resposta. El filtratge encara fa més sorollós el senyal, perquè un tallafoc que bloqueja peticions d'eco no diu res dels ports que hi ha darrere. I un perfil amb túnel dividit pot excloure deliberadament l'adreça provada mentre totes les altres destinacions funcionen.

El que realment voleu saber és si un servei concret és utilitzable pel camí que pren l'aplicació. Trieu l'amfitrió i el port que crida l'aplicació i després exigiu una resposta a la capa d'aplicació.

L'abastabilitat i l'estat del túnel són fets diferents, i qualsevol dels dos pot ser cert mentre l'altre és fals. Mantenir-los separats us diu de qui és la fallada. Ajuntar-los en una sola comprovació produeix un tiquet que ningú no pot encaminar.

Pregunteu a Android pel transport, no per un ping

Android respon la pregunta d'estat directament mitjançant ConnectivityManager. Les capacitats de la xarxa activa porten un indicador de transport VPN, que s'estableix quan el trànsit s'encamina per una interfície VPN. La crida és local, barata i independent de si respon algun amfitrió remot.

Aquesta versió de Java retorna false en lloc de llançar una excepció quan no hi ha cap xarxa activa. Com que llegeix la xarxa activa, reflecteix el perfil que l'usuari ha triat a Configuració.

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

Per a les notificacions de canvi, registreu una NetworkCallback en lloc de consultar amb un temporitzador. No ho confongueu amb VpnService.prepare, que només informa si l'usuari ha concedit permís per a una VPN, no si hi ha paquets circulant. La revocació arriba per VpnService.onRevoke, però oblidar un perfil a Configuració no produeix cap difusió.

iOS: els noms d'interfície són una heurística, no un contracte

Molts fragments d'iOS inspeccionen la configuració del proxy, troben el diccionari __SCOPED__ i busquen claus d'interfície com tap, tun, utun2, ppp o ipsec. Aquest enfocament és una convenció de noms, no una garantia documentada, així que una actualització del sistema que reanomeni una interfície el pot trencar. També tendeix a informar cert per a entrades antigues que sobreviuen al túnel.

Quan la vostra aplicació és propietària de la configuració, NEVPNManager us dona un estat real. Descriu el túnel que ha iniciat la vostra aplicació; amb una VPN per aplicació, altres aplicacions poden quedar completament fora d'aquest túnel.

Recarregueu les preferències abans de llegir l'estat, perquè el valor canvia a mesura que el túnel apareix i desapareix:

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

Un indicador d'estat de la plataforma encara no demostra que el trànsit arribi a l'igual. Aquest buit és el que cobreix la prova de ruta, i per això un sol booleà no n'hi ha prou per al suport.

Els perfils de Windows exposen un camp d'estat real

Windows fa el seguiment dels perfils VPN per separat dels adaptadors, i Get-VpnConnection exposa un ConnectionStatus per a cada perfil que coneix. Aquí hi apareixen els perfils creats amb el client de Windows o amb un paquet de subministrament. El cmdlet no és un detector general de túnels.

Llegiu el camp per a un perfil amb nom, afegint -AllUserConnection quan el perfil és de tots els usuaris:

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

Els clients de tercers sovint resten invisibles per a aquest cmdlet fins i tot quan el seu túnel està actiu, així que un resultat buit vol dir desconegut, no desconnectat. Els llistats d'adaptadors enganyen igual: un adaptador de fabricant pot persistir quan està inactiu, i alguns adaptadors només existeixen durant una sessió. Per a un perfil que Windows posseeix, rasdial informa d'un codi de sortida sobre el qual podeu ramificar. Tot això descriu una creença local, no l'abastabilitat de l'igual.

Estat més ruta: la comprovació en dues parts

Un perfil connectat no diu res sobre on van els paquets. El túnel dividit pot mantenir el túnel actiu mentre exclou la destinació que us importa. Els perfils always-on resten connectats amb un servidor mort, i un kill switch bloqueja el trànsit deliberadament quan el túnel cau.

Proveu les dues capes: confirmeu que un transport VPN o un perfil és actiu i després que la destinació es resol i respon per aquest camí. A Linux, pregunteu al nucli quina interfície faria servir:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Quan el client queda fora del vostre control, registreu tots dos resultats i deixeu que el patró assenyali la capa. Connectat més una prova de ruta fallida suggereix túnel dividit, DNS o política. Desconnectat més una prova de ruta correcta vol dir que un altre camí porta el trànsit.

Una prova que podeu executar en ordre

Registreu primer l'estat de la plataforma, abans de canviar qualsevol estat de xarxa. Resoleu el nom d'amfitrió i anoteu la família d'adreces, perquè un registre AAAA pot prendre un camí diferent d'un registre A. Obriu el port del servei i exigiu una resposta d'aplicació en lloc d'un simple handshake. Guardeu cada observació en el seu propi camp de registre.

En una màquina Linux amb dig i curl, tres ordres cobreixen la resolució, la ruta i el servei mateix. Executeu-les amb el túnel actiu i de nou amb el túnel caigut:

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

Quatre camps separats superen un sol booleà, perquè l'estat, el DNS, la ruta i la política fallen de manera independent i arriben a equips diferents. Un ping al terminal segueix sent una bona comprovació manual de salut. És una mala definició de connectivitat per a l'automatització, on l'API de la plataforma i una prova de ruta responen la pregunta real.

Articles relacionats