Gespeichertes Mac-VPN mit scutil --nc im Terminal starten

Nutzen Sie scutil --nc, um einen gespeicherten macOS-VPN-Dienst zu starten, zu prüfen und zu stoppen, halten Sie Anmeldedaten aus argv heraus und belegen Sie, dass der Datenverkehr wirklich den Tunnel nutzt.

Sie haben einen gespeicherten VPN-Dienst in den Systemeinstellungen, und das Terminal soll ihn starten. Unter macOS ist der unterstützte Weg scutil --nc, aber nur für Dienste, die dem eigenen Netzwerkverbindungsmanager des Systems gehören. Die Menüleiste ist nicht die API: Drittanbieter-Clients haben meist ihre eigene Automatisierung, und ein von einem Verwaltungsdienst bereitgestelltes Profil kann einen lokalen Start verweigern. Das ist die Checkliste, die ich abarbeite: den exakten Dienst finden, seinen Zustand lesen, ihn starten, auf die Zustandsänderung warten und dann belegen, dass der Datenverkehr wirklich den Tunnel nutzt. Halt beim ersten Schritt an, der nicht passt, denn jeder spätere Befehl setzt voraus, dass der vorherige erfolgreich war.

Den Dienst finden, bevor Sie ihn zu starten versuchen

Beginnen Sie mit dem Inventar statt mit dem Profilnamen, den Sie erinnern:

scutil --nc help
scutil --nc list

Jede Zeile verbindet einen Status mit einer Dienstkennung, einem Typ und einem Anzeigenamen. Die Kennung ist der Wert, gegen den skriptet wird, weil Anzeigenamen sich wiederholen und bearbeitet werden können. Apples scutil-Handbuch dokumentiert den Netzwerkverbindungsmodus, während das installierte --nc help die maßgebliche Liste der Unterbefehle auf diesem Mac ist; nehmen Sie nicht an, dass ein Schalter aus einer älteren Anleitung in Ihrer macOS-Version noch existiert.

Eine leere Liste ist ein Ergebnis, kein Fehler. Ein Dienst, der von einem Anbieter-Client oder einem Verwaltungsprofil erstellt wurde, kann aktiv sein, während er hier unsichtbar ist, oder sichtbar mit einem Typ, den der native Controller nicht steuern kann. Verwenden Sie in diesem Fall das Werkzeug des Anbieters oder die Profildokumentation. Ein paralleles natives Profil anzulegen, nur um etwas zum Starten zu haben, ist ein schlechter Tausch.

Den aktuellen Zustand lesen und den Selektor bestätigen

Fragen Sie den Dienst ab, bevor Sie ihn starten, damit Sie wissen, was ein erfolgreicher Start ändern sollte:

scutil --nc status "Office VPN"

Wenn zwei Dienste denselben Anzeigenamen teilen, ist der Name mehrdeutig. Übergeben Sie stattdessen die Kennung; der Befehl akzeptiert beides, aber nur die Kennung wählt garantiert genau einen Dienst aus. Prüfen Sie, dass das Statuswort eines ist, das Sie kennen — typischerweise Connected, Disconnected, Connecting oder Disconnecting —, bevor Sie es in einem Skript auswerten. Prüfen Sie außerdem, ob das Profil verwaltet wird, denn eine gesperrte Konfiguration kann den Befehl annehmen und ihn trotzdem ignorieren oder nach einer Bestätigung fragen.

Dieser Zustandsabruf ist billig, nutzen Sie ihn daher als Wächter in der Automatisierung: Starten Sie nur, wenn der Status Disconnected ist, und behandeln Sie Connecting nicht als Fehler. Wenn der Dienst bereits Connected ist, überspringen Sie den Start, statt einen funktionierenden Tunnel zu unterbrechen.

Die Verbindung starten und auf den stabilen Zustand warten

Die Startanfrage ist asynchron. Der Befehl kehrt zurück, wenn die Anfrage angenommen wurde, nicht wenn die Authentifizierung abgeschlossen ist oder Routen installiert sind. Führen Sie ihn aus, fragen Sie dann den Zustand mit begrenzter Wartezeit ab, und brechen Sie ab, wenn der Dienst auf Disconnected zurückfällt:

scutil --nc start "Office VPN"
n=0
while [ "$n" -lt 30 ]; do
  state=$(scutil --nc status "Office VPN" | head -n 1)
  [ "$state" = "Connected" ] && break
  [ "$state" = "Disconnected" ] && { echo "start failed"; exit 1; }
  sleep 2
  n=$((n + 1))
done

Ein Connecting-Status, der nie aufgelöst wird, deutet meist auf Anmeldedaten, MFA oder den Server hin, nicht auf scutil. Der Befehl kann keine interaktive Anmeldung liefern, daher bleibt ein Profil, das ein Token oder einen Hardwareschlüssel erwartet, in Connecting hängen und fällt schließlich zurück. Lesen Sie das Statuswort, bevor Sie Wiederholungen ergänzen; eine Schleife gegen eine Authentifizierungsaufforderung kann nicht gelingen.

Behandeln Sie den Exit-Status der Shell nicht als Bereitschaft. Das nützliche Signal ist die Zustandszeichenfolge, gefolgt von einem Beleg, dass der Tunnel Datenverkehr trägt. Ein Startbefehl, der still zurückkehrt, kann Sie dennoch mit einer Verbindung zurücklassen, die nie authentifiziert.

Belegen, dass der Tunnel Datenverkehr trägt, nicht nur dass er Connected sagt

Connected beschreibt die Verbindung, nicht die Routingentscheidung. Native PPP- und IKEv2-Dienste erzeugen eine ppp- oder utun-Schnittstelle und installieren Routen, während ein Split-Tunneling die Standardroute bewusst unangetastet lässt. Prüfen Sie die Schnittstellen und beide Adressfamilien:

ifconfig -l
netstat -rn -f inet
netstat -rn -f inet6
scutil --dns

Finden Sie die Schnittstelle, die der Dienst erstellt hat, statt eine Nummer zu raten, und fragen Sie dann die Routingtabelle, welche Schnittstelle ein bestimmtes Ziel verwendet: route -n get 10.0.0.10, mit einem internen Host an dieser Stelle. Wenn sie die physische Schnittstelle meldet, ist der Tunnel aktiv, trägt aber diesen Fluss nicht. Prüfen Sie Split-Tunneling-Routen, Resolver-Reihenfolge und jede lokale Firewall-Regel, die die Tunnelschnittstelle erlaubt, aber nicht den Prozess.

Die Namensauflösung ist das übliche falsche Negativ. Interne Namen können über den falschen Resolver aufgelöst werden, während der Tunnel völlig gesund ist, was wie ein VPN-Fehler aussieht und keiner ist. scutil --dns zeigt die Reihenfolge, die macOS verwenden wird; nach einer Resolver-Änderung leeren Sie den Cache mit dscacheutil -flushcache und sudo killall -HUP mDNSResponder.

Anmeldedaten und Privilegien aus der Befehlszeile heraushalten

Setzen Sie niemals ein Kennwort, einen vorab geteilten Schlüssel oder ein Token in die Argumente. Argumente sind in Prozesslisten sichtbar und landen in der Shell-Historie, und ein kopiertes Support-Protokoll kann sie preisgeben. Die eigene Anmeldedatenverwaltung des Profils — ob Keychain-Eintrag, Systemabfrage oder Authentifizierungsfluss des Clients — ist der Ort für Geheimnisse.

Der Befehl mit sudo macht eine interaktive Anmeldung nicht unbeaufsichtigt. Er ändert den effektiven Benutzer, nicht die Verfügbarkeit einer GUI-Abfrage, eines Hardware-Tokens oder des Anmelde-Keychains. Ein LaunchAgent kann einen Dienst starten, nachdem sich der Benutzer angemeldet hat und der Keychain entsperrt ist; ein LaunchDaemon erreicht diese Teile der Benutzersitzung normalerweise nicht. Wenn eine Organisation den Dienst verwaltet, gewinnen deren Lebenszyklusregeln gegenüber jedem lokalen Skript.

Den Dienst stoppen und prüfen, dass er gestoppt bleibt

Stoppen Sie mit demselben Selektor, den Sie zum Starten verwendet haben, und lesen Sie dann den Zustand erneut, statt anzunehmen, der Tunnel sei weg:

scutil --nc stop "Office VPN"
scutil --nc status "Office VPN"

Ein Stopp, der zu Disconnected zurückkehrt, lässt noch eine Sache zu prüfen: ob das Profil auf Verbindung bei Bedarf eingestellt ist, was es ohne Ihr Skript zurückbringen kann. Wenn ein anderer Client Routen auf demselben Mac besitzt, können diese Routen einen nativen Stopp überleben. Prüfen Sie die Route erneut, bevor Sie schließen, dass die Maschine außerhalb des VPN ist.

Für einen Wrapper, den Sie von Hand ausführen, halten Sie die Reihenfolge fest: Liste, Status, Start, Abfrage, Routentest, Stopp, Prüfung. Werten Sie den freundlichen Namen nicht aus freier Ausgabe aus, wenn die Kennung verfügbar ist, und behandeln Sie den Exit des Startbefehls nicht als Bereitschaft. Der Verbindungsmanager meldet den Zustand; Ihr Beleg ist der Zustand plus eine Route, die auf den Tunnel zeigt.

Ähnliche Artikel