Sådan tjekker du VPN-status uden ping på Android, iOS og Windows

Ping beviser kun, at én vært svarede, ikke at tunnelen er oppe. Spørg Androids, iOS' og Windows' status-API'er, og verificér derefter den rute, din app faktisk har brug for.

At pinge 192.0.2.10 fortæller dig, at én adresse svarede på et ICMP-ekko, og det er alt. På et netværk uden tunnel kan det stadig lykkes, fordi adressen kan ligge på det lokale undernet; med en sund tunnel kan det mislykkes, fordi serveren dropper ICMP, mens den betjener HTTPS. Den kontrol, dit script skal bruge, er en statusforespørgsel på platformen plus en rutetest til det mål, applikationen bruger. Behandl dem som to separate felter, aldrig som én boolean.

Hvad et ekko-svar egentlig beviser

ICMP er en tilgængelighedsprotokol uden begreb om interfaces eller tunneler. Når et svar ankommer, rapporterer kernen, at en vært svarede; den rapporterer ikke, hvilken rute der bar forespørgslen, eller hvilken der bar svaret. Filtrering gør signalet endnu mere støjende, fordi en firewall, der blokerer ekko-forespørgsler, ikke siger noget om portene bagved. Og en split-tunnel-profil kan bevidst udelade den testede adresse, mens alle andre mål virker.

Det, du faktisk vil vide, er, om en bestemt tjeneste kan bruges ad den vej, appen tager. Vælg den vært og port, appen kalder, og kræv derefter et svar på applikationslaget.

Tilgængelighed og tunnelstatus er forskellige fakta, og hver af dem kan være sand, mens den anden er falsk. At holde dem adskilt fortæller dig, hvem der ejer fejlen. At slå dem sammen i én kontrol giver en sag, som ingen kan route.

Spørg Android om transporten, ikke om et ping

Android besvarer statusspørgsmålet direkte gennem ConnectivityManager. Det aktive netværks egenskaber bærer et VPN-transportflag, som sættes, når trafikken routes gennem et VPN-interface. Kaldet er lokalt, billigt og uafhængigt af, om en fjern vært svarer.

Denne Java-version returnerer false i stedet for at kaste en undtagelse, når der ikke er noget aktivt netværk. Fordi den læser det aktive netværk, afspejler den den profil, brugeren har valgt i Indstillinger.

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

Til ændringsnotifikationer skal du registrere en NetworkCallback i stedet for at polle på en timer. Forveksl ikke det med VpnService.prepare, som kun rapporterer, om brugeren har givet tilladelse til en VPN, ikke om pakker flyder. Tilbagekaldelse kommer gennem VpnService.onRevoke, men at glemme en profil i Indstillinger giver slet ingen udsendelse.

iOS: interfacenavne er en heuristik, ikke en kontrakt

Mange iOS-snippets undersøger proxyindstillingerne, finder __SCOPED__-ordbogen og leder efter interface-nøgler som tap, tun, utun2, ppp eller ipsec. Den tilgang er en navngivningskonvention, ikke en dokumenteret garanti, så en OS-opdatering, der omdøber et interface, kan bryde den. Den har også tendens til at rapportere sandt for forældede poster, der overlever tunnelen.

Når din app ejer konfigurationen, giver NEVPNManager dig en rigtig status. Den beskriver den tunnel, din app startede; med en VPN pr. app kan andre apps ligge helt uden for den tunnel.

Genindlæs indstillingerne, før du læser status, fordi værdien ændrer sig, når tunnelen kommer og går:

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

Et statusflag på platformen beviser stadig ikke, at trafikken når peer'en. Det hul er det, rutetesten dækker, og derfor er én boolean ikke nok for support.

Windows-profiler viser et rigtigt statusfelt

Windows sporer VPN-profiler adskilt fra netværkskort, og Get-VpnConnection viser en ConnectionStatus for hver profil, den kender. Profiler oprettet via Windows-klienten eller en provisioning-pakke dukker op her. Cmdlet'en er ikke en generel tunneldetektor.

Læs feltet for en navngivet profil, og tilføj -AllUserConnection, når profilen tilhører alle brugere:

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

Tredjepartsklienter er ofte usynlige for denne cmdlet, selv mens deres tunnel er oppe, så et tomt resultat betyder ukendt, ikke afbrudt. Lister over netværkskort er lige så misvisende: et leverandørkort kan bestå, mens det er inaktivt, og nogle kort findes kun under en session. For en profil, Windows ejer, rapporterer rasdial en exitkode, du kan forgrene på. Alt dette beskriver en lokal antagelse, ikke peer-tilgængelighed.

Status plus rute: kontrollen i to dele

En tilsluttet profil siger intet om, hvor pakkerne går hen. Split tunneling kan holde tunnelen oppe, mens den udelader det mål, du bekymrer dig om. Always-on-profiler forbliver tilsluttet en død server, og en kill switch blokerer bevidst trafik, når tunnelen falder.

Test begge lag: bekræft, at en VPN-transport eller profil er aktiv, og bekræft derefter, at målet opløses og svarer ad den vej. På Linux kan du spørge kernen, hvilket interface den ville bruge:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Når klienten er uden for din kontrol, log begge resultater og lad mønstret pege på laget. Tilsluttet plus en mislykket rutetest tyder på split tunneling, DNS eller politik. Afbrudt plus en fungerende rutetest betyder, at en anden vej bærer trafikken.

En test, du kan køre i rækkefølge

Registrér først platformens status, før du ændrer nogen netværkstilstand. Slå værtsnavnet op, og notér adressefamilien, fordi en AAAA-post kan tage en anden vej end en A-post. Åbn tjenestens port, og kræv et applikationssvar i stedet for et bart håndtryk. Hold hver observation i sit eget logfelt.

På en Linux-boks med dig og curl dækker tre kommandoer opslag, rute og selve tjenesten. Kør dem med tunnelen oppe og igen med den 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 felter slår én boolean, fordi status, DNS, rute og politik fejler uafhængigt og lander hos forskellige teams. Et ping i terminalen er stadig en fin manuel sanity check. Det er en dårlig definition af forbindelse til automatisering, hvor platformens API og en rutetest besvarer det egentlige spørgsmål.

Relaterede artikler