Slik sjekkar du VPN-status utan ping på Android, iOS og Windows

Å pinge 192.0.2.10 fortel deg berre at éi adresse svara på eit ICMP-ekko, og ikkje noko meir. På eit nettverk utan tunnel kan det likevel lukkast, fordi adressa kan liggje på det lokale subnettet; med ein sunn tunnel kan det mislukkast, fordi tenaren droppar ICMP medan han leverer HTTPS. Sjekken skriptet ditt treng, er eit statusspørsmål til plattforma pluss ein rutetest mot destinasjonen appen brukar. Handsama dei som to separate felt, aldri som éin boolsk verdi.

Kva eit ekkosvar faktisk beviser

ICMP er ein tilgjengeprotokoll som ikkje har noko omgrep om grensesnitt eller tunnelar. Når eit svar kjem, rapporterer kjernen at ein vert svara; han rapporterer ikkje kva rute som bar førespurnaden, eller kva som bar svaret. Filtrering gjer signalet endå meir støyande, fordi ein brannmur som blokkerer ekkoførespurnader ikkje seier noko om portane bak han. Og ein profil med delt tunnel kan med vilje utelate den testa adressa medan alle andre destinasjonar verkar.

Det du eigentleg vil vite, er om ei bestemd teneste er brukbar over vegen appen tek. Vel verten og porten appen kallar, og krev deretter eit svar på applikasjonslaget.

Tilgjenge og tunnelstatus er ulike faktum, og den eine kan vere sann medan den andre er usann. Held du dei frå kvarandre, veit du kven som eig feilen. Slår du dei saman til éin sjekk, får du ei sak ingen kan rute.

Spør Android om transporten, ikkje om ping

Android svarar direkte på statusspørsmålet gjennom ConnectivityManager. Eigenskapane til det aktive nettet ber eit VPN-transportflagg som blir sett når trafikken blir ruta gjennom eit VPN-grensesnitt. Kallet er lokalt, billeg og uavhengig av om ein fjern vert svarar.

Denne Java-versjonen returnerer false i staden for å kaste eit unntak når det ikkje finst noko aktivt nett. Fordi han les det aktive nettet, speglar han profilen brukaren valde i Innstillingar.

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

For endringsvarsel registrerer du ein NetworkCallback i staden for å polle med ein timer. Ikkje forveksle det med VpnService.prepare, som berre melder om brukaren gav løyve til VPN, ikkje om pakkane flyt. Tilbakekalling kjem via VpnService.onRevoke, men å gløyme ein profil i Innstillingar gir ingen kringkasting i det heile.

iOS: grensesnittnamn er ein heuristikk, ikkje ein kontrakt

Mange iOS-utdrag undersøkjer proxy-innstillingane, finn __SCOPED__-ordboka og leitar etter grensesnittnøklar som tap, tun, utun2, ppp eller ipsec. Den tilnærminga er ein namnekonvensjon, ikkje ein dokumentert garanti, så ein OS-oppdatering som gjev eit grensesnitt nytt namn kan øydeleggje han. Han har òg ein tendens til å rapportere true for forelda oppføringar som overlever tunnelen.

Når appen din eig konfigurasjonen, gir NEVPNManager ein ekte status i staden. Han skildrar tunnelen appen din starta; med VPN per app kan andre apper stå heilt utanfor den tunnelen.

Last inn innstillingane på nytt før du les statusen, fordi verdien endrar seg når tunnelen kjem og går:

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

Eit statusflagg frå plattforma beviser framleis ikkje at trafikken når peeren. Det gapet er det rutetesten dekkjer, og difor er éin boolsk verdi ikkje nok for støtte.

Windows-profilar eksponerer eit ekte statusfelt

Windows sporar VPN-profilar åtskilde frå adapterar, og Get-VpnConnection eksponerer ein ConnectionStatus for kvar profil han kjenner. Profilar laga via Windows-klienten eller ein provisjoneringspakke dukkar opp her. Cmdleten er ikkje ein generell tunneldetektor.

Les feltet for ein namngjeven profil, og legg til -AllUserConnection når profilen høyrer til alle brukarar:

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

Tredjepartsklientar blir ofte usynlege for denne cmdleten sjølv når tunnelen deira er oppe, så eit tomt resultat tyder ukjend, ikkje fråkopla. Adapterlister villeder like mykje: ein leverandøradapter kan bestå medan han er inaktiv, og nokre adapterar finst berre i ein sesjon. For ein profil Windows eig, rapporterer rasdial ein utgangskode du kan forgreine på. Alt dette skildrar lokal tru, ikkje peer-tilgjenge.

Status pluss rute: den todelte sjekken

Ein tilkopla profil seier ingenting om kvar pakkane går. Delt tunnellering kan halde tunnelen oppe medan han utelèt destinasjonen du bryr deg om. Always-on-profilar blir verande tilkopla med ein død tenar, og ein kill switch blokkerer trafikk med vilje når tunnelen fell.

Test båe laga: stadfest at ein VPN-transport eller profil er aktiv, og stadfest deretter at destinasjonen blir løyst opp og svarar langs den ruta. På Linux, spør kjernen kva grensesnitt han ville brukt:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Når klienten er utanfor din kontroll, logg båe resultata og lat mønsteret peike på laget. Tilkopla pluss ein mislukka rutetest tyder på delt tunnellering, DNS eller policy. Fråkopla pluss ein fungerande rutetest tyder at ein annan veg ber trafikken.

Ein test du kan køyre i rekkjefølgje

Registrer plattformstatusen først, før du endrar nokon nettverkstilstand. Løys opp vertsnamnet og noter adressefamilien, fordi ei AAAA-oppføring kan ta ein annan veg enn ei A-oppføring. Opne tenestporten og krev eit applikasjonssvar i staden for berre eit handtrykk. Hald kvar observasjon i sitt eige loggfelt.

På ein Linux-boks med dig og curl dekkjer tre kommandoar oppslag, rute og tenesta sjølv. Køyr dei med tunnelen oppe og igjen når han er nede:

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

Fire separate felt slår éin boolsk verdi, fordi status, DNS, rute og policy feilar uavhengig og endar hos ulike team. Ping i terminalen er framleis ein god manuell sjekk. Det er ein dårleg definisjon av tilkopling for automatisering, der API-et til plattforma og ein rutetest svarar på det eigentlege spørsmålet.