VPN-status controleren zonder ping op Android, iOS en Windows

Een ping naar 192.0.2.10 vertelt je alleen dat één adres op een ICMP-echo heeft geantwoord, en meer niet. Op een netwerk zonder tunnel kan het toch lukken, omdat het adres op het lokale subnet kan liggen; met een gezonde tunnel kan het mislukken, omdat de server ICMP laat vallen terwijl hij HTTPS bedient. De controle die je script nodig heeft, is een statusbevraging van het platform plus een routetest naar de bestemming die de applicatie gebruikt. Behandel ze als twee afzonderlijke velden, nooit als één boolean.

Wat een echoreactie werkelijk bewijst

ICMP is een bereikbaarheidsprotocol dat geen begrip heeft van interfaces of tunnels. Wanneer er een reactie komt, meldt de kernel dat een host heeft geantwoord; hij meldt niet welke route het verzoek droeg of welke het antwoord droeg. Filtering maakt het signaal nog ruisiger, omdat een firewall die echoverzoeken blokkeert niets zegt over de poorten erachter. En een profiel met split tunneling kan het geteste adres bewust uitsluiten terwijl elke andere bestemming werkt.

Wat je echt wilt weten, is of een bepaalde dienst bruikbaar is over het pad dat de app aflegt. Kies de host en poort die de app aanroept, en eis dan een antwoord op applicatieniveau.

Bereikbaarheid en tunnelstatus zijn verschillende feiten, en het ene kan waar zijn terwijl het andere onwaar is. Ze gescheiden houden vertelt je van wie de storing is. Ze samenvoegen tot één controle levert een ticket op dat niemand kan routeren.

Vraag Android naar het transport, niet naar een ping

Android beantwoordt de statusvraag rechtstreeks via ConnectivityManager. De mogelijkheden van het actieve netwerk dragen een VPN-transportvlag, die wordt gezet wanneer verkeer via een VPN-interface wordt gerouteerd. De aanroep is lokaal, goedkoop en onafhankelijk van of een externe host antwoordt.

Deze Java-versie retourneert false in plaats van een uitzondering te gooien wanneer er geen actief netwerk is. Omdat hij het actieve netwerk leest, weerspiegelt hij het profiel dat de gebruiker in Instellingen heeft gekozen.

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

Registreer voor wijzigingsmeldingen een NetworkCallback in plaats van met een timer te pollen. Verwar dat niet met VpnService.prepare, dat alleen meldt of de gebruiker toestemming voor een VPN gaf, niet of er pakketten stromen. Intrekking komt via VpnService.onRevoke, maar een profiel vergeten in Instellingen levert helemaal geen broadcast op.

iOS: interfacenamen zijn een heuristiek, geen contract

Veel iOS-fragmenten inspecteren de proxyinstellingen, vinden het __SCOPED__-woordenboek en zoeken naar interfacesleutels zoals tap, tun, utun2, ppp of ipsec. Die aanpak is een naamconventie, geen gedocumenteerde garantie, dus een OS-update die een interface hernoemt kan hem breken. Hij rapporteert ook graag true voor verouderde vermeldingen die de tunnel overleven.

Wanneer je app de configuratie bezit, geeft NEVPNManager een echte status. Het beschrijft de tunnel die je app is gestart; met een VPN per app kunnen andere apps volledig buiten die tunnel staan.

Laad de voorkeuren opnieuw voordat je de status leest, want de waarde verandert terwijl de tunnel opkomt en wegvalt:

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

Een statusvlag van het platform bewijst nog steeds niet dat verkeer de peer bereikt. Precies die kloof dekt de routetest, en daarom is één boolean niet genoeg voor support.

Windows-profielen bieden een echt statusveld

Windows volgt VPN-profielen apart van adapters, en Get-VpnConnection biedt een ConnectionStatus voor elk profiel dat het kent. Profielen die via de Windows-client of een provisioningpakket zijn gemaakt, verschijnen hier. De cmdlet is geen algemene tunneldetector.

Lees het veld voor een genoemd profiel, en voeg -AllUserConnection toe wanneer het profiel van alle gebruikers is:

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

Clients van derden blijven vaak onzichtbaar voor deze cmdlet, zelfs wanneer hun tunnel actief is, dus een leeg resultaat betekent onbekend, niet losgekoppeld. Adapterlijsten misleiden net zo goed: een leveranciersadapter kan blijven bestaan terwijl hij inactief is, en sommige adapters bestaan alleen tijdens een sessie. Voor een profiel dat Windows bezit, meldt rasdial een exitcode waarop je kunt vertakken. Dit alles beschrijft lokale overtuiging, niet bereikbaarheid van de peer.

Status plus route: de tweedelige controle

Een verbonden profiel zegt niets over waar de pakketten heen gaan. Split tunneling kan de tunnel in stand houden terwijl de bestemming die je belangrijk vindt wordt uitgesloten. Always-on-profielen blijven verbonden met een dode server, en een kill switch blokkeert verkeer bewust wanneer de tunnel wegvalt.

Test beide lagen: bevestig dat een VPN-transport of profiel actief is, bevestig dan dat de bestemming langs die route wordt opgelost en antwoordt. Op Linux, vraag de kernel welke interface hij zou gebruiken:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Wanneer de client buiten je controle valt, log dan beide resultaten en laat het patroon de laag aanwijzen. Verbonden plus een mislukte routetest wijst op split tunneling, DNS of beleid. Losgekoppeld plus een werkende routetest betekent dat een ander pad het verkeer draagt.

Een test die je op volgorde kunt uitvoeren

Leg eerst de platformstatus vast, voordat je enige netwerkstatus wijzigt. Los de hostnaam op en noteer de adresfamilie, omdat een AAAA-record een ander pad kan nemen dan een A-record. Open de dienstpoort en eis een applicatieantwoord in plaats van alleen een handshake. Houd elke observatie in een eigen logveld.

Op een Linux-machine met dig en curl dekken drie commando's resolutie, route en de dienst zelf. Voer ze uit met de tunnel actief en opnieuw wanneer hij uit staat:

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 afzonderlijke velden verslaan één boolean, omdat status, DNS, route en beleid onafhankelijk falen en bij verschillende teams terechtkomen. Een ping in de terminal blijft een goede handmatige controle. Het is een slechte definitie van connectiviteit voor automatisering, waar de platform-API en een routetest de werkelijke vraag beantwoorden.