VPN na Macu przy starcie: launchd nadzoruje zadanie, nie tunel

Zadanie uruchamia się przy logowaniu, log pokazuje start klienta, ale tunel nigdy nie wstaje. Albo wstaje i znika kilka sekund później. W obu przypadkach lista właściwości była prawdopodobnie w porządku. launchd złożył dwie obietnice, przyjmując zadanie: będzie nadzorował proces i ten proces będzie działał dalej. VPN potrzebuje obu, a poprawny plik XML nie daje żadnej.

Poprawna lista właściwości to jeszcze nie działająca usługa

plutil -lint sprawdza strukturę. Nie powie ci, czy plik binarny istnieje, czy argumenty są obsługiwane przez tę wersję klienta ani czy zadanie startuje w kontekście, w którym dostępne są poświadczenia. To pytania semantyczne i wyjaśniają większość awarii, które wyglądają jak problemy z launchd.

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

Przeczytaj wynik drugiego polecenia, zamiast zakładać, że zadanie zostało wczytane. Podaje on ostatni status wyjścia i informację, czy usługa działa, co pozwala odróżnić „nigdy nie wystartowało” od „wystartowało i padło”, zanim tkniesz profil.

Agenci dziedziczą sesję użytkownika, demony nie

Dokumentacja Apple dotycząca launchd rozdziela agentów poszczególnych użytkowników od demonów systemowych. Agent działa w kontekście zalogowanego użytkownika, z jego pękiem kluczy i środowiskiem. Demon działa bez tej sesji, a przeniesienie zadania do katalogu systemowego nie odtwarza interaktywnych poświadczeń użytkownika.

To ta różnica decyduje o projekcie. Jeśli połączenie wymaga, by człowiek się zalogował lub zatwierdził monit MFA, wspieranym układem jest zadanie w sesji użytkownika uruchamiane po zalogowaniu. Jeśli ma działać bez zalogowanego człowieka, klient potrzebuje zatwierdzonej tożsamości bezobsługowej z własnym procesem odnowienia i unieważnienia. Wybór niewłaściwego wiersza daje zadanie, które startuje czysto i zawodzi na pierwszym kroku uwierzytelniania.

Nie zakrywaj tej różnicy hasłem w tablicy argumentów ani wyłączaniem sprawdzania certyfikatów. Oba zamieniają wymóg uwierzytelnienia w trwały sekret w czytelnym pliku, a to drugie oznacza, że tunel uwierzytelnia wszystko, co odpowiada.

Nadzór działa tylko wtedy, gdy proces pozostaje z przodu

Klient, który sam się demonizuje, natychmiast oddaje sterowanie launchdowi, a nadzorca patrzy wtedy na proces, który już się zakończył. Tunel może być włączony, ale launchd uważa, że zadanie zawiodło, a jego polityka restartu zrobi coś, czego nie zamierzałeś.

Użyj udokumentowanego trybu pierwszego planu lub trybu usługi klienta. Jeśli produkt ma własną wspieraną funkcję startową, ona już wie, jak pozostać z przodu i jak przekazać sterowanie stosowi sieciowemu; własne zadanie to odrębny projekt, a nie jej ulepszenie.

Nadaj zadaniu unikalną etykietę, zamierzony plik wykonywalny i przemyślaną tablicę argumentów. Tablica nie jest wierszem poleceń powłoki, więc potoki i przekierowania tam nie działają, a zachowanie cudzysłowów jest inne. Polecenie, które udaje się w terminalu administratora, jest co najwyżej wstępnym sprawdzeniem.

Poświadczenia muszą działać bez monitu

Praca bezobsługowa przenosi problem poświadczeń, zamiast go usuwać. Ktoś musi być właścicielem tożsamości, zdecydować, jak długo żyje, i udokumentować, jak jest wymieniana. Certyfikat bez monitorowania terminu ważności staje się awarią z datą w kalendarzu.

Trzymaj sekrety poza argumentami i poza standardowym wyjściem zadania. Jeśli klient obsługuje odczyt poświadczenia z chronionego magazynu, użyj tej drogi i sprawdź, czy kontekst wykonania zadania może dotrzeć do magazynu. Demon działający jako root zwykle nie może odczytać elementu pęku kluczy logowania, a to rodzaj szczegółu, który ujawnia się tylko w kontekście systemowym.

Zdefiniuj, co znaczy gotowe, i testuj właśnie tam

Udany start dowodzi, że proces się rozpoczął. Nie dowodzi, że sieć działa, że brama zaakceptowała tożsamość ani że aplikacja prywatna jest osiągalna. Jeśli coś innego zależy od tunelu, potrzebuje sygnału gotowości odzwierciedlającego połączenie, a nie czasu startu zadania.

Ponowienia powinny być ograniczone i powinny odróżniać brak sieci od odrzuconych poświadczeń. Ponowne uruchamianie przy każdym błędzie nie naprawi wygasłego certyfikatu i tworzy log pełen identycznych prób, który ukrywa tę prawdziwą.

Zaakceptuj zadanie w kontekście, w którym naprawdę będzie działać: bez sieci przy starcie, przy normalnym logowaniu, po wybudzeniu ze snu i przy kontrolowanym zatrzymaniu. Następnie zapisz razem etykietę zadania, wersję klienta i rewizję profilu, aby następna osoba odziedziczyła usługę, którą można przypisać, a nie plik, który kiedyś działał.