Slik sjekker du VPN-status uten ping på Android, iOS og Windows

Ping beviser bare at én vert svarte, ikke at tunnelen er oppe. Spør status-API-ene i Android, iOS og Windows, og verifiser deretter ruten appen din faktisk trenger.

Å pinge 192.0.2.10 forteller deg bare at én adresse svarte på et ICMP-ekko, og ikke noe mer. På et nettverk uten tunnel kan det likevel lykkes, fordi adressen kan ligge på det lokale subnettet; med en sunn tunnel kan det mislykkes, fordi serveren dropper ICMP mens den leverer HTTPS. Sjekken skriptet ditt trenger, er et statusspørsmål til plattformen pluss en rutetest mot destinasjonen appen bruker. Behandle dem som to separate felt, aldri som én boolsk verdi.

Hva et ekkosvar faktisk beviser

ICMP er en tilgjengelighetsprotokoll som ikke har noe begrep om grensesnitt eller tunneler. Når et svar kommer, rapporterer kjernen at en vert svarte; den rapporterer ikke hvilken rute som bar forespørselen, eller hvilken som bar svaret. Filtrering gjør signalet enda mer støyende, fordi en brannmur som blokkerer ekkoforespørsler ikke sier noe om portene bak den. Og en profil med delt tunnel kan med vilje utelate den testede adressen mens alle andre destinasjoner virker.

Det du egentlig vil vite, er om en bestemt tjeneste er brukbar over veien appen tar. Velg verten og porten appen kaller, og krev deretter et svar på applikasjonslaget.

Tilgjengelighet og tunnelstatus er forskjellige fakta, og den ene kan være sann mens den andre er usann. Holder du dem fra hverandre, vet du hvem som eier feilen. Slår du dem sammen til én sjekk, får du en sak ingen kan rute.

Spør Android om transporten, ikke om ping

Android svarer direkte på statusspørsmålet gjennom ConnectivityManager. Det aktive nettverkets egenskaper bærer et VPN-transportflagg som settes når trafikken rutes gjennom et VPN-grensesnitt. Kallet er lokalt, billig og uavhengig av om en fjern vert svarer.

Denne Java-versjonen returnerer false i stedet for å kaste et unntak når det ikke finnes noe aktivt nettverk. Fordi den leser det aktive nettverket, gjenspeiler den profilen brukeren valgte i Innstillinger.

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

For endringsvarsler registrerer du en NetworkCallback i stedet for å polle med en timer. Ikke forveksle det med VpnService.prepare, som bare melder om brukeren ga tillatelse til VPN, ikke om pakkene flyter. Tilbakekalling kommer via VpnService.onRevoke, men å glemme en profil i Innstillinger gir ingen kringkasting i det hele tatt.

iOS: grensesnittnavn er en heuristikk, ikke en kontrakt

Mange iOS-utdrag undersøker proxy-innstillingene, finner __SCOPED__-ordboken og leter etter grensesnittnøkler som tap, tun, utun2, ppp eller ipsec. Den tilnærmingen er en navnekonvensjon, ikke en dokumentert garanti, så en OS-oppdatering som gir et grensesnitt nytt navn kan ødelegge den. Den har også en tendens til å rapportere true for foreldede oppføringer som overlever tunnelen.

Når appen din eier konfigurasjonen, gir NEVPNManager en ekte status i stedet. Den beskriver tunnelen appen din startet; med VPN per app kan andre apper stå helt utenfor den tunnelen.

Last inn innstillingene på nytt før du leser statusen, fordi verdien endres når tunnelen kommer og går:

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

Et statusflagg fra plattformen beviser fortsatt ikke at trafikken når peeren. Det gapet er det rutetesten dekker, og derfor er én boolsk verdi ikke nok for support.

Windows-profiler eksponerer et ekte statusfelt

Windows sporer VPN-profiler atskilt fra adaptere, og Get-VpnConnection eksponerer en ConnectionStatus for hver profil den kjenner. Profiler laget via Windows-klienten eller en provisjoneringspakke dukker opp her. Cmdleten er ikke en generell tunneldetektor.

Les feltet for en navngitt profil, og legg til -AllUserConnection når profilen tilhører alle brukere:

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

Tredjepartsklienter forblir ofte usynlige for denne cmdleten selv når tunnelen deres er oppe, så et tomt resultat betyr ukjent, ikke frakoblet. Adapterlister villeder like mye: en leverandøradapter kan bestå mens den er inaktiv, og noen adaptere finnes bare i en sesjon. For en profil Windows eier, rapporterer rasdial en utgangskode du kan forgrene på. Alt dette beskriver lokal tro, ikke peer-tilgjengelighet.

Status pluss rute: den todelte sjekken

En tilkoblet profil sier ingenting om hvor pakkene går. Delt tunnellering kan holde tunnelen oppe mens den utelater destinasjonen du bryr deg om. Always-on-profiler forblir tilkoblet med en død server, og en kill switch blokkerer trafikk med vilje når tunnelen faller.

Test begge lagene: bekreft at en VPN-transport eller profil er aktiv, og bekreft deretter at destinasjonen løses opp og svarer langs den ruten. På Linux, spør kjernen hvilket grensesnitt den ville brukt:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Når klienten er utenfor din kontroll, logg begge resultatene og la mønsteret peke på laget. Tilkoblet pluss en mislykket rutetest antyder delt tunnellering, DNS eller policy. Frakoblet pluss en fungerende rutetest betyr at en annen vei bærer trafikken.

En test du kan kjøre i rekkefølge

Registrer plattformstatusen først, før du endrer noen nettverkstilstand. Løs opp vertsnavnet og noter adressefamilien, fordi en AAAA-oppføring kan ta en annen vei enn en A-oppføring. Åpne tjenesteporten og krev et applikasjonssvar i stedet for bare et håndtrykk. Hold hver observasjon i sitt eget loggfelt.

På en Linux-boks med dig og curl dekker tre kommandoer oppslag, rute og tjenesten selv. Kjør dem med tunnelen oppe og igjen når den 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 én boolsk verdi, fordi status, DNS, rute og policy feiler uavhengig og ender hos forskjellige team. Ping i terminalen er fortsatt en god manuell sjekk. Det er en dårlig definisjon av tilkobling for automatisering, der plattformens API og en rutetest svarer på det egentlige spørsmålet.

Relaterte artikler