VPN på Mac vid start: launchd övervakar jobbet, inte tunneln

Jobbet körs vid inloggning, loggen visar att klienten startar, men tunneln kommer aldrig upp. Eller så kommer den upp och försvinner några sekunder senare. I båda fallen var egenskapslistan förmodligen i ordning. launchd gav två löften när den tog emot jobbet: den ska övervaka en process, och den processen ska fortsätta köra. VPN behöver båda, och en korrekt XML-fil ger ingen av dem.

En giltig egenskapslista är inte en fungerande tjänst

plutil -lint kontrollerar strukturen. Den kan inte säga om binären finns, om argumenten stöds av den här klientversionen, eller om jobbet startar i en kontext där inloggningsuppgifterna är tillgängliga. Det är semantiska frågor, och de förklarar de flesta fel som ser ut som launchd-problem.

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

Läs utdata från det andra kommandot i stället för att anta att jobbet är laddat. Det rapporterar senaste utgångsstatus och om tjänsten körs, vilket skiljer «startade aldrig» från «startade och dog» innan du rör profilen.

Agenter ärver en användarsession, demoner gör det inte

Apples launchd-dokumentation skiljer agenter per användare från systemdemoner. En agent körs i den inloggade användarens kontext, med användarens nyckelring och miljö. En demon körs utan den sessionen, och att flytta ett jobb till en systemkatalog återskapar inte användarens interaktiva inloggningsuppgifter.

Det är den här skillnaden som avgör utformningen. Om anslutningen kräver att en person loggar in eller godkänner en MFA-förfrågan är den stödda lösningen ett jobb i användarsessionen som körs efter inloggning. Om den måste fungera utan att någon är inloggad behöver klienten en godkänd obevakad identitet med egen förnyelse- och återkallningsprocess. Att välja fel rad ger ett jobb som startar rent och misslyckas i första autentiseringssteget.

Dölj inte skillnaden med ett lösenord i argumentmatrisen eller genom att stänga av certifikatkontroller. Båda gör ett autentiseringskrav till en permanent hemlighet i en läsbar fil, och det andra innebär att tunneln autentiserar allt som svarar.

Övervakning fungerar bara om processen stannar i förgrunden

En klient som gör sig själv till demon lämnar tillbaka kontrollen till launchd direkt, och övervakaren tittar då på en process som redan har avslutats. Tunneln kan vara uppe, men launchd tror att jobbet misslyckades, och dess omstartspolicy gör något du inte avsåg.

Använd klientens dokumenterade förgrunds- eller tjänsteläge. Om produkten har en egen stödd startfunktion vet den redan hur den ska stanna i förgrunden och hur den överlämnar till nätverksstacken; ett eget jobb är en separat design, inte en förbättring av den.

Ge jobbet en unik etikett, den avsedda körbara filen och en medveten argumentmatris. En matris är inte en skalkommandorad, så rör och omdirigeringar fungerar inte där, och citattecken beter sig annorlunda. Ett kommando som lyckas i en administratörsterminal är i bästa fall en preliminär kontroll.

Inloggningsuppgifter måste fungera utan fråga

Obevakad drift flyttar inloggningsproblemet i stället för att ta bort det. Någon måste äga identiteten, bestämma hur länge den lever och dokumentera hur den ersätts. Ett certifikat utan övervakning av utgång blir ett avbrott med ett datum i kalendern.

Håll hemligheter utanför argumenten och utanför jobbets standardutdata. Om klienten stöder läsning av inloggningsuppgifter från ett skyddat lager, använd den vägen, och kontrollera att jobbets körningskontext kan nå lagret. En demon som körs som root kan vanligtvis inte läsa ett objekt i inloggningsnyckelringen, och det är den typen av detalj som bara dyker upp i systemkontexten.

Definiera vad klart betyder och testa där

En lyckad start bevisar att processen började. Den bevisar inte att nätverket är uppe, att gatewayen accepterade identiteten eller att den privata applikationen går att nå. Om något annat beror på tunneln behöver det en beredskapssignal som speglar anslutningen, inte jobbets starttid.

Nya försök bör vara begränsade och bör skilja ett saknat nätverk från en avvisad inloggningsuppgift. Att starta om vid varje fel kan inte reparera ett utgånget certifikat och ger en logg full av identiska försök som döljer det verkliga.

Acceptera jobbet i den kontext där det faktiskt ska köras: inget nätverk vid start, en normal inloggning, en uppvakning ur sömn och ett kontrollerat stopp. Anteckna sedan jobbets etikett, klientversionen och profilrevisionen tillsammans, så att nästa person ärver en spårbar tjänst i stället för en fil som en gång fungerade.