Hoe om VPN-status op Android, iOS en Windows sonder ping na te gaan

Ping bewys net dat een gasheer geantwoord het, nie dat die tonnel op is nie. Vra die status-API's van Android, iOS en Windows, en verifieer dan die roete wat jou app werklik nodig het.

Om 192.0.2.10 te ping vertel jou dat een adres op 'n ICMP-echo geantwoord het, en dit is al wat dit jou vertel. Op 'n netwerk sonder tonnel kan dit steeds slaag, want die adres kan op die plaaslike subnet sit; met 'n gesonde tonnel kan dit misluk, want die bediener laat ICMP val terwyl dit HTTPS bedien. Die kontrole wat jou script nodig het, is 'n platformstatus-navraag plus 'n roetetoets vir die bestemming wat die toepassing gebruik. Hanteer dié as twee afsonderlike velde, nooit as een booleaanse waarde nie.

Wat 'n echo-antwoord werklik bewys

ICMP is 'n bereikbaarheidsprotokol sonder begrip van interfaces of tonnels. Wanneer 'n antwoord aankom, rapporteer die kernel dat 'n gasheer geantwoord het; dit rapporteer nie die roete wat die versoek gedra het of die een wat die antwoord gedra het nie. Filtering maak die sein nog ruier, want 'n firewall wat echo-versoeke blokkeer, sê niks oor die poorte agter dit nie. En 'n split-tonnel-profiel kan die getoetsde adres doelbewus uitsluit terwyl elke ander bestemming werk.

Wat jy eintlik wil weet, is of 'n spesifieke diens bruikbaar is oor die pad wat die app neem. Kies die gasheer en poort wat die app aanroep, en vereis dan 'n antwoord op die toepassingslaag.

Bereikbaarheid en tonneltoestand is verskillende feite, en enige een kan waar wees terwyl die ander onwaar is. Om hulle apart te hou, sê vir jou wie die fout besit. Om hulle in een kontrole saam te voeg, lewer 'n kaartjie wat niemand kan routeer nie.

Vra Android vir die transport, nie vir 'n ping nie

Android beantwoord die statusvraag direk deur ConnectivityManager. Die aktiewe netwerk se vermoëns dra 'n VPN-transportvlag, wat gestel word wanneer verkeer deur 'n VPN-koppelvlak gestuur word. Die oproep is plaaslik, goedkoop en onafhanklik van of enige afgeleë gasheer antwoord.

Hierdie Java-weergawe gee false terug eerder as om 'n fout te gooi wanneer daar geen aktiewe netwerk is nie. Omdat dit die aktiewe netwerk lees, weerspieël dit die profiel wat die gebruiker in Instellings gekies het.

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

Vir veranderingkennisgewings, registreer 'n NetworkCallback in plaas daarvan om op 'n tydhouer te poll. Moenie dit met VpnService.prepare verwar nie, wat net rapporteer of die gebruiker toestemming vir 'n VPN gegee het, nie of pakkette vloei nie. Herroeping kom deur VpnService.onRevoke, maar om 'n profiel in Instellings te vergeet, lewer glad geen uitsending nie.

iOS: koppelvlakname is 'n heuristiek, nie 'n kontrak nie

Baie iOS-brokke ondersoek die instaanbediener-instellings, vind die __SCOPED__-woordeboek en soek koppelvlakname soos tap, tun, utun2, ppp of ipsec. Daardie benadering is 'n naamkonvensie, nie 'n gedokumenteerde waarborg nie, so 'n opdatering van die bedryfstelsel wat 'n koppelvlak hernoem, kan dit breek. Dit is ook geneig om waar te rapporteer vir verouderde inskrywings wat die tonnel oorleef.

Wanneer jou app die konfigurasie besit, gee NEVPNManager jou 'n werklike status. Dit beskryf die tonnel wat jou app begin het; met 'n per-app-VPN kan ander apps heeltemal buite daardie tonnel sit.

Herlaai die voorkeure voordat jy die status lees, want die waarde verander soos die tonnel kom en gaan:

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

'n Platformstatusvlag bewys steeds nie dat verkeer die eweknie bereik nie. Daardie gaping is wat die roetetoets dek, en dit is waarom een booleaanse waarde nie genoeg is vir ondersteuning nie.

Windows-profiele bied 'n werklike statusveld

Windows hou VPN-profiele apart van adapters, en Get-VpnConnection bied 'n ConnectionStatus vir elke profiel wat dit ken. Profiele wat deur die Windows-kliënt of 'n voorsieningspakket geskep is, verskyn hier. Die cmdlet is nie 'n algemene tonnelverklikker nie.

Lees die veld vir 'n genoemde profiel, en voeg -AllUserConnection by wanneer die profiel aan alle gebruikers behoort:

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

Derdeparty-kliënte bly dikwels onsigbaar vir hierdie cmdlet selfs terwyl hulle tonnel op is, so 'n leë resultaat beteken onbekend, nie ontkoppel nie. Adapterlyste is ewe misleidend: 'n verskafferadapter kan bly voortbestaan terwyl dit ledig is, en sommige adapters bestaan net tydens 'n sessie. Vir 'n profiel wat Windows besit, rapporteer rasdial 'n uitgangskode waarop jy kan vertak. Al hierdie dinge beskryf plaaslike oortuiging, nie bereikbaarheid van die eweknie nie.

Status plus roete: die tweeledige kontrole

'n Gekoppelde profiel sê niks oor waar pakkette heen gaan nie. Split-tunneling kan die tonnel op hou terwyl dit die bestemming wat jy sorg uitsluit. Always-on-profiele bly gekoppel met 'n dooie bediener, en 'n kill switch blokkeer verkeer doelbewus wanneer die tonnel val.

Toets albei lae: bevestig dat 'n VPN-transport of -profiel aktief is, en bevestig dan dat die bestemming oplos en langs daardie pad antwoord. Op Linux, vra die kernel watter koppelvlak dit sou gebruik:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Wanneer die kliënt buite jou beheer is, teken albei resultate aan en laat die patroon na die laag wys. Gekoppel plus 'n mislukte roetetoets dui op split-tunneling, DNS of beleid. Ontkoppel plus 'n werkende roetetoets beteken 'n ander pad dra die verkeer.

'n Toets wat jy in volgorde kan uitvoer

Teken eers die platformstatus aan, voordat jy enige netwerktoestand verander. Los die gasheernaam op en let op die adresfamilie, want 'n AAAA-rekord kan 'n ander pad as 'n A-rekord volg. Maak die dienspoort oop en eis 'n toepassingsantwoord eerder as 'n blote handdruk. Hou elke waarneming in sy eie logveld.

Op 'n Linux-boks met dig en curl dek drie opdragte oplossing, roete en die diens self. Voer hulle uit met die tonnel op en weer met dit af:

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

Vier afsonderlike velde klop een booleaanse waarde, want status, DNS, roete en beleid faal onafhanklik en beland by verskillende spanne. 'n Terminal-ping bly 'n goeie handmatige saniteitskontrole. Dit is 'n swak definisie van verbinding vir outomatisering, waar die platform-API en 'n roetetoets die werklike vraag beantwoord.

Verwante artikels