Mac-VPN beim Start: launchd überwacht den Job, nicht den Tunnel

Der Job läuft beim Login, das Protokoll zeigt den startenden Client, und der Tunnel kommt nie hoch. Oder er kommt hoch und verschwindet wenige Sekunden später. In beiden Fällen war die Eigenschaftenliste wahrscheinlich in Ordnung. launchd gab zwei Versprechen, als er den Job annahm: Er überwacht einen Prozess, und dieser Prozess läuft weiter. Das VPN braucht beides, und eine korrekte XML-Datei liefert keins von beidem.

Eine gültige Eigenschaftenliste ist kein laufender Dienst

plutil -lint prüft die Struktur. Es kann nicht sagen, ob die Binärdatei existiert, ob die Argumente von dieser Client-Version unterstützt werden oder ob der Job in einem Kontext startet, in dem die Anmeldedaten verfügbar sind. Das sind semantische Fragen, und sie erklären die meisten Fehler, die wie launchd-Probleme aussehen.

plutil -lint /Library/LaunchDaemons/com.example.vpn.plist
launchctl print system/com.example.vpn

Lesen Sie die Ausgabe des zweiten Befehls, statt anzunehmen, der Job sei geladen. Sie meldet den letzten Exit-Status und ob der Dienst läuft, was „nie gestartet“ von „gestartet und gestorben“ unterscheidet, bevor Sie das Profil anfassen.

Agents erben eine Benutzersitzung, Daemons nicht

Apples launchd-Dokumentation trennt benutzerbezogene Agents von System-Daemons. Ein Agent läuft im Kontext des angemeldeten Benutzers, mit dessen Schlüsselbund und Umgebung. Ein Daemon läuft ohne diese Sitzung, und ein Job in einem Systemverzeichnis erzeugt die interaktiven Anmeldedaten des Benutzers nicht neu.

Diese Unterscheidung entscheidet das Design. Wenn die Verbindung verlangt, dass sich eine Person anmeldet oder eine MFA-Abfrage bestätigt, ist die unterstützte Anordnung ein Job in der Benutzersitzung, der nach dem Login läuft. Muss er ohne angemeldete Person funktionieren, braucht der Client eine genehmigte unbeaufsichtigte Identität mit eigenem Erneuerungs- und Widerrufsverfahren. Die falsche Zeile zu wählen erzeugt einen Job, der sauber startet und beim ersten Authentifizierungsschritt scheitert.

Übertünchen Sie den Unterschied nicht mit einem Passwort im Argumentarray oder durch Abschalten der Zertifikatsprüfungen. Beides macht aus einer Authentifizierungsanforderung ein dauerhaftes Geheimnis in einer lesbaren Datei, und das Zweite bedeutet, dass der Tunnel alles authentifiziert, was antwortet.

Überwachung funktioniert nur, wenn der Prozess im Vordergrund bleibt

Ein Client, der sich selbst zum Daemon macht, gibt die Kontrolle sofort an launchd zurück, und der Supervisor beobachtet dann einen Prozess, der bereits beendet ist. Der Tunnel kann stehen, aber launchd hält den Job für gescheitert, und seine Neustartrichtlinie tut etwas, das Sie nicht beabsichtigt haben.

Verwenden Sie den dokumentierten Vordergrund- oder Dienstmodus des Clients. Hat das Produkt eine eigene unterstützte Startfunktion, weiß diese bereits, wie man im Vordergrund bleibt und wie man an den Netzwerk-Stack übergibt; ein eigener Job ist ein separates Design, keine Verbesserung davon.

Geben Sie dem Job ein eindeutiges Label, die vorgesehene ausführbare Datei und ein bewusstes Argumentarray. Ein Array ist keine Shell-Kommandozeile, daher funktionieren Pipes und Umleitungen dort nicht, und Anführungszeichen verhalten sich anders. Ein Befehl, der im Terminal eines Administrators gelingt, ist bestenfalls eine Vorabprüfung.

Anmeldedaten müssen ohne Abfrage funktionieren

Unbeaufsichtigter Betrieb verschiebt das Anmeldedatenproblem, statt es zu beseitigen. Jemand muss die Identität besitzen, entscheiden, wie lange sie lebt, und dokumentieren, wie sie ersetzt wird. Ein Zertifikat ohne Überwachung des Ablaufs wird zu einem Ausfall mit einem Datum im Kalender.

Halten Sie Geheimnisse aus Argumenten und aus der Standardausgabe des Jobs heraus. Unterstützt der Client das Lesen von Anmeldedaten aus einem geschützten Speicher, nutzen Sie diesen Weg und prüfen Sie, ob der Ausführungskontext des Jobs den Speicher erreicht. Ein als root laufender Daemon kann normalerweise keinen Eintrag im Login-Schlüsselbund lesen, und das ist die Art Detail, die nur im Systemkontext auftaucht.

Definieren Sie, was bereit bedeutet, und testen Sie es dort

Ein erfolgreicher Start beweist, dass der Prozess begonnen hat. Er beweist nicht, dass das Netzwerk steht, dass das Gateway die Identität akzeptiert hat oder dass die private Anwendung erreichbar ist. Hängt etwas anderes vom Tunnel ab, braucht es ein Bereitschaftssignal, das die Verbindung widerspiegelt, nicht die Startzeit des Jobs.

Wiederholungen sollten begrenzt sein und ein fehlendes Netzwerk von abgelehnten Anmeldedaten unterscheiden. Ein Neustart bei jedem Fehler kann ein abgelaufenes Zertifikat nicht reparieren und erzeugt ein Protokoll voller identischer Versuche, das den echten verdeckt.

Akzeptieren Sie den Job in dem Kontext, in dem er tatsächlich läuft: kein Netzwerk beim Start, ein normaler Login, ein Aufwachen aus dem Ruhezustand und ein kontrolliertes Stoppen. Halten Sie dann Job-Label, Client-Version und Profilrevision zusammen fest, damit die nächste Person einen zuordenbaren Dienst erbt statt einer Datei, die einmal funktioniert hat.