Mac-VPN-Status: Profil, Ressource oder Flow prüfen

Jemand fragt, ob das VPN steht, und drei verschiedene Personen meinen damit drei verschiedene Dinge. Ein Betriebsverantwortlicher meint, dass das Office-Profil die Authentifizierung abgeschlossen hat. Ein Scheduler meint, dass die private API antworten wird. Eine Sicherheitsprüfung meint, dass diese konkrete Anfrage den geschützten Pfad verlassen hat. Ein Skript, das die Routentabelle nach einem Schnittstellennamen durchsucht, beantwortet keine dieser Fragen zuverlässig.

Die Checkliste beginnt also, bevor ein Befehl läuft: Benennen Sie das Subjekt der Prüfung. Alles danach ist die Wahl der Schnittstelle, die es tatsächlich melden kann.

Das Subjekt vor dem Befehl benennen

Formulieren Sie die Frage als Prädikat mit Subjekt. „Ist das Office-Profil verbunden“ ist prüfbar und hat einen Verantwortlichen, der sie beantworten kann. „Kann dieser Job die interne API erreichen“ ist ein zweites Prädikat mit einem anderen Fehlermodus. „Nutzt diese Anfrage den geschützten Pfad“ ist ein drittes, und es ist das einzige, das von einem einzelnen Flow spricht statt von der ganzen Maschine.

Ihre Vermischung erzeugt Automatisierung, die selbstsicher lügt. Ein Job, der den Profilzustand prüft und dann annimmt, die API sei bereit, alarmiert jemanden in der falschen Schicht, und ein Job, der die API anpingt und das als Beweis eines Tunnels ausgibt, kann ein funktionierendes VPN nicht von einem Laptop unterscheiden, der zufällig im Büronetz hängt.

Ein Profil: das zuständige Objekt fragen

Für einen nativen Mac-Dienst melden die Netzwerkverbindungs-Steuerungen in scutil genau das. Sie lesen den Zustand einer benannten Konfiguration, statt etwas aus einer Schnittstelle abzuleiten.

scutil --nc list
scutil --nc status "Office VPN"

Der Profilname in diesem Befehl muss der echte aus der Listenausgabe sein, keine Vermutung. Dies ist ein schreibgeschützter Pfad für native Dienste, und es ist keine Garantie, dass ein Drittanbieter-Client dort überhaupt auftaucht; ein Anbieter, der seinen eigenen Tunnel verwaltet, braucht seine eigene unterstützte Statusschnittstelle. Prüfen Sie die Liste, bevor Sie den Statusaufruf schreiben, damit ein fehlender Name sichtbar scheitert, statt still nichts zu treffen.

In einer Network-Extension-App lesen Sie den Status aus den Manager- und Verbindungsobjekten statt aus dem System. Achten Sie hier auf den Geltungsbereich: Das Laden gespeicherter Konfigurationen liefert nur die von der aufrufenden App erzeugten, ein leeres Ergebnis bedeutet also „keine von mir“ und nicht „kein VPN auf diesem Mac“. Unterscheiden Sie eine fehlgeschlagene Abfrage von einem bestätigten getrennten Zustand, und behandeln Sie Übergangszustände als eigene Ergebnisse, statt eine Verbindung erneut zu versuchen, die bereits im Aufbau ist.

Ein Job: Bereitschaft ist ein eigenes Prädikat

Wenn die Frage ist, ob ein Job fortfahren kann, prüfen Sie die tatsächliche Abhängigkeit des Jobs, nachdem der Verbindungsverantwortliche den beabsichtigten Zustand gemeldet hat. Eine begrenzte Bereitschaftsprüfung gegen die private Ressource ist die richtige Form: Sie beweist, was der Job braucht, und nichts darüber hinaus.

Sie kann weiterhin nicht beweisen, dass jede Anfrage auf der Maschine den Tunnel nutzt, und sie sollte nicht so gemeldet werden, als könnte sie es. Ebenso ist eine Ressource, die über das gewöhnliche Netz antwortet, kein Beleg für ein VPN; deshalb bleiben die beiden Prüfungen getrennt, auch wenn beide gelingen.

Wenn der Job wirklich einen geschützten Pfad benötigt, braucht diese Anforderung das eigene Durchsetzungsdesign der Bereitstellung: Routing, Split-Tunnel-Ausnahmen, eine Firewall-Regel oder eine Anforderung auf Anwendungsebene. Die Verfügbarkeit eines Endpunkts ist eine Tatsache über einen Server. Durchsetzung ist eine Tatsache über die Konfiguration des Clients, und das eine belegt das andere nicht.

Ein Flow: die gewählte Route prüfen

Für einen einzelnen Flow betrachten Sie Ziel, Adressfamilie und Quellkontext mit der Routing-Diagnose, die den gewählten Pfad für genau dieses Ziel meldet. Diese Ausgabe nennt die tatsächlich genutzte Schnittstelle und Quelladresse, was eine deutlich stärkere Aussage ist als ein Eintrag in der Standardroute.

Breite Browser-Prüfungen beantworten eine ganz andere Frage. Ein Ergebnis zur öffentlichen IP beschreibt, wie eine Anfrage aus Sicht eines Servers aussah, und sagt nichts über privates DNS, ausgeschlossene Anwendungen oder einen zweiten Netzwerkkontext, den ein anderer Prozess nutzt.

Ein Ergebnis zurückgeben, das der Aufrufer nutzen kann

Wählen Sie eine Rückgabeform, die zum Prädikat passt: einen benannten Profilzustand, ein Urteil zur Ressourcenbereitschaft oder ein ausdrückliches Unbekannt mit den Belegen, die dazu geführt haben. Behalten Sie die Identität der Konfiguration und die Fehlerursache neben dem Urteil bei.

Diese letzte Gewohnheit macht den Unterschied zwischen Automatisierung, die hilft, und Automatisierung, die Probleme verbirgt. „Office VPN: getrennt, letzter Versuch bei der Authentifizierung fehlgeschlagen“ sagt einem Betriebsverantwortlichen, wo er nachsehen muss. „VPN ist weg“ lädt zu einer Neuinstallation ein, und „Schnittstelle gefunden“ lädt zu einem falschen Alles-in-Ordnung ein.

Die Network-Extension-Referenz zum Laden gespeicherter Tunnelkonfigurationen ist der Ort, an dem Sie den Geltungsbereich der aufrufenden App bestätigen, bevor Sie etwas darauf aufbauen.