So prüfen Sie den VPN-Status unter Android, iOS und Windows ohne Ping

Ein Ping belegt nur, dass ein Host geantwortet hat, nicht dass der Tunnel steht. Fragen Sie die Status-APIs von Android, iOS und Windows ab und prüfen Sie dann die Route, die Ihre App tatsächlich braucht.

Ein Ping auf 192.0.2.10 sagt Ihnen, dass eine Adresse auf ein ICMP-Echo geantwortet hat, und mehr nicht. In einem Netz ohne Tunnel kann er trotzdem gelingen, weil die Adresse im lokalen Subnetz liegen kann; bei einem gesunden Tunnel kann er fehlschlagen, weil der Server ICMP verwirft, während er HTTPS bedient. Die Prüfung, die Ihr Skript braucht, ist eine Statusabfrage der Plattform plus ein Routentest für das Ziel, das die Anwendung nutzt. Behandeln Sie beides als zwei getrennte Felder, niemals als einen Boolean.

Was eine Echo-Antwort tatsächlich belegt

ICMP ist ein Erreichbarkeitsprotokoll ohne Begriff von Schnittstellen oder Tunneln. Wenn eine Antwort eintrifft, meldet der Kernel, dass ein Host geantwortet hat; er meldet nicht, welche Route die Anfrage oder die Antwort getragen hat. Filterung macht das Signal noch rauschiger, denn eine Firewall, die Echo-Anfragen blockiert, sagt nichts über die Ports dahinter. Und ein Split-Tunnel-Profil kann die getestete Adresse bewusst ausschließen, während jedes andere Ziel funktioniert.

Was Sie wirklich wissen wollen, ist, ob ein bestimmter Dienst über den Pfad nutzbar ist, den die App nimmt. Wählen Sie Host und Port, die die App aufruft, und verlangen Sie dann eine Antwort auf der Anwendungsebene.

Erreichbarkeit und Tunnelzustand sind verschiedene Fakten, und jedes kann wahr sein, während das andere falsch ist. Getrennt gehalten sagen sie Ihnen, wem der Fehler gehört. Zu einer Prüfung verschmolzen ergeben sie ein Ticket, das niemand weiterleiten kann.

Fragen Sie Android nach dem Transport, nicht nach einem Ping

Android beantwortet die Statusfrage direkt über den ConnectivityManager. Die Fähigkeiten des aktiven Netzes tragen ein VPN-Transport-Flag, das gesetzt wird, wenn Datenverkehr über eine VPN-Schnittstelle geroutet wird. Der Aufruf ist lokal, günstig und unabhängig davon, ob irgendein entfernter Host antwortet.

Diese Java-Version gibt false zurück, statt eine Ausnahme zu werfen, wenn es kein aktives Netz gibt. Weil sie das aktive Netz liest, spiegelt sie das Profil wider, das der Nutzer in den Einstellungen gewählt hat.

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

Für Änderungsbenachrichtigungen registrieren Sie einen NetworkCallback, statt per Timer zu pollen. Verwechseln Sie das nicht mit VpnService.prepare, das nur meldet, ob der Nutzer eine VPN-Berechtigung erteilt hat, nicht ob Pakete fließen. Ein Widerruf kommt über VpnService.onRevoke, doch das Vergessen eines Profils in den Einstellungen erzeugt überhaupt keinen Broadcast.

iOS: Schnittstellennamen sind eine Heuristik, kein Vertrag

Viele iOS-Schnipsel untersuchen die Proxy-Einstellungen, finden das __SCOPED__-Wörterbuch und suchen nach Schnittstellenschlüsseln wie tap, tun, utun2, ppp oder ipsec. Dieser Ansatz ist eine Namenskonvention, keine dokumentierte Garantie, daher kann ein OS-Update, das eine Schnittstelle umbenennt, ihn brechen. Er neigt außerdem dazu, für veraltete Einträge wahr zu melden, die den Tunnel überleben.

Wenn Ihre App die Konfiguration besitzt, liefert NEVPNManager einen echten Status. Er beschreibt den Tunnel, den Ihre App gestartet hat; bei einem VPN pro App können andere Apps völlig außerhalb dieses Tunnels liegen.

Laden Sie die Einstellungen neu, bevor Sie den Status lesen, denn der Wert ändert sich, während der Tunnel kommt und geht:

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

Ein Statusflag der Plattform belegt trotzdem nicht, dass der Verkehr den Peer erreicht. Genau diese Lücke deckt der Routentest ab, und deshalb reicht ein Boolean für den Support nicht aus.

Windows-Profile legen ein echtes Statusfeld offen

Windows verfolgt VPN-Profile getrennt von Adaptern, und Get-VpnConnection legt für jedes bekannte Profil einen ConnectionStatus offen. Profile, die über den Windows-Client oder ein Bereitstellungspaket erstellt wurden, erscheinen hier. Das Cmdlet ist kein allgemeiner Tunneldetektor.

Lesen Sie das Feld für ein benanntes Profil und ergänzen Sie -AllUserConnection, wenn das Profil allen Benutzern gehört:

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

Drittanbieter-Clients bleiben für dieses Cmdlet oft unsichtbar, selbst während ihr Tunnel steht, ein leeres Ergebnis bedeutet also unbekannt, nicht getrennt. Adapterlisten täuschen ebenso: Ein Herstelleradapter kann bestehen bleiben, während er untätig ist, und manche Adapter existieren nur während einer Sitzung. Für ein Profil, das Windows besitzt, meldet rasdial einen Exit-Code, auf den Sie verzweigen können. All das beschreibt eine lokale Annahme, nicht die Erreichbarkeit des Peers.

Status plus Route: die zweiteilige Prüfung

Ein verbundenes Profil sagt nichts darüber, wohin Pakete gehen. Split Tunneling kann den Tunnel oben halten und dabei das Ziel ausschließen, das Ihnen wichtig ist. Always-on-Profile bleiben mit einem toten Server verbunden, und ein Kill Switch blockiert den Verkehr absichtlich, wenn der Tunnel fällt.

Testen Sie beide Schichten: Bestätigen Sie, dass ein VPN-Transport oder Profil aktiv ist, und dann, dass das Ziel aufgelöst wird und über diesen Pfad antwortet. Fragen Sie unter Linux den Kernel, welche Schnittstelle er verwenden würde:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Wenn der Client außerhalb Ihrer Kontrolle liegt, protokollieren Sie beide Ergebnisse und lassen Sie das Muster auf die Schicht zeigen. Verbunden plus ein fehlgeschlagener Routentest deutet auf Split Tunneling, DNS oder Richtlinie hin. Getrennt plus ein funktionierender Routentest heißt, dass ein anderer Pfad den Verkehr trägt.

Ein Test, den Sie der Reihe nach ausführen können

Erfassen Sie zuerst den Plattformstatus, bevor Sie irgendeinen Netzwerkzustand ändern. Lösen Sie den Hostnamen auf und notieren Sie die Adressfamilie, denn ein AAAA-Eintrag kann einen anderen Pfad nehmen als ein A-Eintrag. Öffnen Sie den Dienstport und verlangen Sie eine Antwort der Anwendung statt eines bloßen Handshakes. Halten Sie jede Beobachtung in ihrem eigenen Logfeld.

Auf einer Linux-Maschine mit dig und curl decken drei Befehle Auflösung, Route und den Dienst selbst ab. Führen Sie sie bei stehendem Tunnel und erneut bei gefallenem Tunnel aus:

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 getrennte Felder schlagen einen Boolean, weil Status, DNS, Route und Richtlinie unabhängig voneinander ausfallen und bei verschiedenen Teams landen. Ein Ping im Terminal bleibt eine gute manuelle Plausibilitätsprüfung. Als Definition von Konnektivität für Automatisierung ist er schlecht, denn dort beantworten die Plattform-API und ein Routentest die eigentliche Frage.

Ähnliche Artikel