So erkennen Sie einen aktiven VPN-Tunnel im Code auf jeder Plattform
Existiert der Tunnel, läuft dieses Ziel durch ihn, oder antwortet das entfernte Ende? Das sind drei verschiedene Prüfungen und drei verschiedene Signale.
„Ist das VPN aktiv?“ sind eigentlich drei Fragen in einem Satz. Welche davon Ihr Code braucht, ist die erste Entscheidung, und genau sie überspringen die meisten Implementierungen. Existiert auf diesem Gerät ein Tunnel, verlässt der Datenverkehr zu diesem Ziel ihn überhaupt, oder antwortet das entfernte Ende mit der Identität, die Sie erwarten. Wählen Sie die Eigenschaft, dann das Signal, das sie misst, und schreiben Sie schließlich ins Protokoll, welche Sie tatsächlich gemessen haben.
Drei Eigenschaften, drei Signale
Auf je eine Zeile verdichtet haben die drei Fragen drei verschiedene Antworten. Die Tabelle unten ist die Entscheidung selbst, nicht ihre Zusammenfassung.
| Property | Signal that answers it | What it still leaves open |
|---|---|---|
| Existence | The platform's own connection state: RAS on Windows, NetworkManager on D-Bus on Linux, scutil on macOS | Tunnels of a type the platform does not manage, which includes most third-party clients |
| Path | A route lookup for the one destination, or a scoped proxy or interface key that names the tunnel | Whether the far end is the peer you trust |
| Identity | An authenticated response from the far end, or a source-address policy applied on the server | Which local interface carried the packets |
Lesen Sie die letzte Zeile langsam. Ein privater Host, der antwortet, beweist, dass etwas geantwortet hat, nicht dass die Antwort durch den Tunnel kam, und er sagt nichts darüber, wer am anderen Ende sitzt. Wenn die Eigenschaft, die Sie brauchen, der Pfad ist, dann messen Sie den Pfad.
Existenz: der eigene Zustand der Plattform
Windows beantwortet dies für native Profile über die Remote Access Service API. RasEnumConnections listet auf, was verbunden ist, RasGetConnectStatus meldet den Zustand eines Eintrags, und RasGetLinkStatistics ergänzt Geschwindigkeit, Bytemesszähler und Verbindungsalter. Die Grenzen sind der Punkt: OpenVPN, WireGuard und Anbieterclients registrieren nie eine RAS-Verbindung, daher zeigt ein gesunder Tunnel dieser Art eine leere Liste, und naiver Code meldet ihn als getrennt.
Linux-Desktops legen dieselbe Eigenschaft über NetworkManager auf D-Bus offen, wo PropertiesChanged am VPN-Verbindungsobjekt die Prüfung in ein Ereignis verwandelt und die Eigenschaft State meldet, wann die Verbindung den Zustand verbunden erreicht. Aus einer Shell liest nmcli connection show --active dieselbe Information, und genau das wollen Sie beim Debuggen. macOS führt diese Liste im Framework System Configuration, mit scutil als Ansicht auf der Kommandozeile. Alle drei beschreiben eine Verbindung, die die Plattform verwaltet, und alle drei verstummen für einen Tunnel, den sie nicht verwaltet.
Pfad: wohin das Paket tatsächlich geht
Namensabgleich ist die Abkürzung, zu der alle zuerst greifen: Schnittstellen auflisten, die Zeichenkette gegen tun, tap, ppp oder ipsec prüfen und einen Treffer als Beweis nehmen. Das ist eine Heuristik, und die Schnittstellenmenge kann gleich aussehen, ob etwas hindurchläuft oder nicht. Ältere iOS-Builds antworteten so, spätere taten es nicht mehr, weil die sichtbaren Schnittstellen die beiden Zustände nicht mehr unterschieden.
Was es dort ersetzt hat, ist das System-Proxy-Wörterbuch. Solange ein VPN verbunden ist, liefert der Aufruf der Proxy-Einstellungen Schlüssel, die auf die tunnelbezogenen Schnittstellen beschränkt sind, und ohne Verbindung kommt das Wörterbuch leer zurück. Das ist eine schwächere Aussage, als es klingt, denn es hält die Systemannahme fest, dass ein Tunnel existiert, statt welches Ziel ihn nutzt.
Android hat seine eigene Version der Falle: Die vpn.connectivity-Übertragung erreicht in manchen Builds im Manifest deklarierte Empfänger und in anderen zur Laufzeit registrierte Empfänger. Behandeln Sie sie als Best-Effort-Maßnahme und halten Sie eine direkte Sonde dahinter bereit.
Wenn das Ziel zählt, fragen Sie die Routing-Tabelle statt die Adapterliste. Standard-Gateway-Heuristiken brechen auf Maschinen mit mehreren Netzen und auf Tunneln, die ihr eigenes Gateway installieren.
Identität: das entfernte Ende prüfen
Eine Schleife, die alle paar Sekunden ein ICMP-Echo an die Gegenseite schickt, ist die billigste Prüfung dieser Art, und sie scheitert in eine nützliche Richtung. Richten Sie sie auf eine Adresse, die nur im privaten Netz existiert, denn eine öffentliche antwortet über jede funktionierende Uplink-Verbindung und beweist gar nichts. Wo ICMP gefiltert wird, leistet eine kurze TCP-Verbindung zum Dienstport dasselbe.
Eine Prüfung auf der Serverseite hat genau ein Signal zur Verfügung: die Quelladresse der Verbindung. Das Pflegen des Bereichsinventars ist laufende Arbeit, und es kann einen Tunnel nicht von jedem anderen Netz trennen, das zufällig denselben Block nutzt.
Grobe Richtlinien können damit leben. Identität kann das nicht, also authentifizieren Sie den Client, statt darauf zu vertrauen, woher seine Pakete zu kommen scheinen.
Die Kategorie protokollieren, nicht das Urteil
Halten Sie die Fehlerkategorien im Protokoll getrennt: gar keine Schnittstelle, Schnittstelle vorhanden, aber das Ziel nicht erreichbar, Ziel erreichbar, aber die Authentifizierung abgelehnt. Das sind drei verschiedene Zuständigkeiten, und jede eröffnet eine andere Untersuchung.
Sie zu einem einzigen „VPN ausgefallen“ zusammenzufassen schickt den Bericht an ein Team, das es nicht beheben kann. Die Kategorie ist die nützliche Ausgabe; das Urteil ist das, was sie falsch macht.