Hoe't jo VPN-status kontrolearje sûnder ping op Android, iOS en Windows

Pingje nei 192.0.2.10 fertelt jo dat ien adres op in ICMP-eko antwurde, en dat is alles. Op in netwurk sûnder tunnel kin it noch slagje, om't it adres yn it lokale subnet lizze kin; mei in sûne tunnel kin it mislearje, om't de server ICMP weilûkt wylst er HTTPS tsjinnet. De kontrôle dy't jo skript nedich hat, is in statusfraach fan it platfoarm plus in rûtetest foar de bestimming dy't de applikaasje brûkt. Behannelje se as twa aparte fjilden, nea as ien boolean.

Wat in eko-antwurd echt bewiist

ICMP is in berikberheidsprotokol sûnder begryp fan ynterfaces of tunnels. As in antwurd oankomt, rapportearret de kernel dat in host antwurde; hy rapportearret net hokker rûte de oanfraach of it antwurd droech. Filtering makket it sinjaal noch rûzer, om't in firewall dy't eko-oanfragen blokkearret neat seit oer de poarten der efter. En in profyl mei split-tunnel kin it teste adres mei opsetsin útslute wylst elke oare bestimming wurket.

Wat jo echt witte wolle, is oft in bepaalde tsjinst brûkber is oer it paad dat de app nimt. Kies de host en poarte dy't de app oanropt, en freegje dan om in antwurd op de applikaasjelaach.

Berikberheid en tunnelstatus binne ferskillende feiten, en elk kin wier wêze wylst it oare falsk is. Se apart hâlde fertelt jo wa't de flater hat. Se gearfoegje ta ien kontrôle jout in ticket dat nimmen routearje kin.

Freegje Android om it ferfier, net om in ping

Android beantwurdet de statusfraach direkt fia ConnectivityManager. De mooglikheden fan it aktive netwurk drage in VPN-ferfiersflagge, dy't ynsteld wurdt as ferkear fia in VPN-ynterface rûte wurde. De oprop is lokaal, goedkeap en ûnôfhinklik fan oft in fiere host antwurdet.

Dizze Java-ferzje jout false werom ynstee fan in útsûndering te smiten as der gjin aktyf netwurk is. Om't it it aktive netwurk lêst, wjerspegelet it it profyl dat de brûker yn Ynstellings keas.

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

Foar feroaringsmeldingen registrearje jo in NetworkCallback ynstee fan mei in timer te ûndersykjen. Betize dat net mei VpnService.prepare, dat allinnich seit oft de brûker tastimming foar in VPN joech, net oft pakketten streame. Yntrekking komt fia VpnService.onRevoke, mar in profyl ferjitte yn Ynstellings jout hielendal gjin útstjoering.

iOS: ynterfacenammen binne in heuristyk, gjin kontrakt

In protte iOS-fragminten ûndersykje de proxy-ynstellings, fine it __SCOPED__-wurdboek en sykje nei ynterface-kaaien lykas tap, tun, utun2, ppp of ipsec. Dy oanpak is in nammekonvinsje, gjin dokumintearre garânsje, dus in OS-fernijing dy't in ynterface omneamt kin it brekke. It hat ek de oanstriid om wier te rapportearjen foar ferâldere ynfieringen dy't de tunnel oerlibje.

As jo app de konfiguraasje besit, jout NEVPNManager jo in echte status. It beskriuwt de tunnel dy't jo app starte; mei in VPN per app kinne oare apps hielendal bûten dy tunnel bliuwe.

Laad de foarkarren opnij foardat jo de status lêze, om't de wearde feroaret as de tunnel komt en giet:

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

In statusflagge fan it platfoarm bewiist noch hieltyd net dat ferkear de peer berikt. Krekt dat gat dekt de rûtetest, en dêrom is ien boolean net genôch foar stipe.

Windows-profylen toane in echt statusfjild

Windows folget VPN-profylen apart fan adapters, en Get-VpnConnection toant in ConnectionStatus foar elk profyl dat it ken. Profylen makke fia de Windows-klant of in provisioning-pakket ferskine hjir. It cmdlet is gjin algemiene tunneldetektor.

Lês it fjild foar in neamd profyl, en foegje -AllUserConnection ta as it profyl fan alle brûkers is:

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

Tredde-partijklanten bliuwe faak ûnsichtber foar dit cmdlet, sels as har tunnel oan is, dus in leech resultaat betsjut ûnbekend, net ferbûn. Adapterlisten misliede likefolle: in fabrikantadapter kin bliuwe wylst er idle is, en guon adapters besteane allinnich yn in sesje. Foar in profyl dat Windows besit, rapportearret rasdial in útgongskoad dêr't jo op fertakje kinne. Dit alles beskriuwt lokale oertsjûging, net berikberheid fan de peer.

Status plus rûte: de twadielige kontrôle

In ferbûn profyl seit neat oer wêr't pakketten hinne gean. Split tunneling kin de tunnel oan hâlde wylst er de bestimming útslút dy't jo wichtich fine. Always-on-profylen bliuwe ferbûn mei in deade server, en in kill switch blokkearret ferkear mei opsetsin as de tunnel falt.

Test beide lagen: befêstigje dat in VPN-ferfier of profyl aktyf is, en dan dat de bestimming oplost en oer dat paad antwurdet. Freegje op Linux de kernel hokker ynterface it brûke soe:

ip route get 192.0.2.10
resolvectl query intranet.example.test

As de klant bûten jo kontrôle is, log dan beide resultaten en lit it patroan nei de laach wiize. Ferbûn plus in mislearre rûtetest wiist op split tunneling, DNS of belied. Net ferbûn plus in wurkjende rûtetest betsjut dat in oar paad it ferkear draacht.

In test dy't jo op folchoarder rinne kinne

Registrearje earst de status fan it platfoarm, foardat jo hokker netwurksteat dan ek feroarje. Los de hostnamme op en notearje de adresfamylje, om't in AAAA-record in oar paad nimme kin as in A-record. Iepenje de poarte fan 'e tsjinst en easkje in applikaasje-antwurd ynstee fan in bleate hânskud. Hâld elke waarnimming yn syn eigen logfjild.

Op in Linux-masine mei dig en curl dekke trije kommando's oplossing, rûte en de tsjinst sels. Rin se mei de tunnel oan en wer mei de tunnel ôf:

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

Fjouwer aparte fjilden ferslaan ien boolean, om't status, DNS, rûte en belied ûnôfhinklik mislearje en by ferskillende teams telâne komme. In ping yn 'e terminal bliuwt in goede hânmjittige kontrôle. Mar it is in minne definysje fan ferbining foar automatisearring, wêr't de API fan it platfoarm en in rûtetest it echte fraachstik beantwurdzje.