Mac-VPN ved opstart: launchd overvåger jobbet, ikke tunnelen

Jobbet kører ved login, loggen viser klienten starter, og tunnelen kommer aldrig op. Eller den kommer op og forsvinder et par sekunder senere. I begge tilfælde var egenskabslisten sandsynligvis i orden. launchd gav to løfter, da den accepterede jobbet: den overvåger en proces, og den proces bliver ved med at køre. VPN har brug for begge, og en korrekt XML-fil giver ingen af dem.

En gyldig egenskabsliste er ikke en fungerende tjeneste

plutil -lint kontrollerer strukturen. Den kan ikke fortælle dig, om binæren findes, om argumenterne understøttes af denne klientversion, eller om jobbet starter i en kontekst, hvor legitimationsoplysningerne er tilgængelige. Det er semantiske spørgsmål, og de forklarer de fleste fejl, der ligner launchd-problemer.

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

Læs outputtet fra den anden kommando i stedet for at antage, at jobbet er indlæst. Den rapporterer den seneste exitstatus, og om tjenesten kører, hvilket skelner “startede aldrig” fra “startede og døde”, før du rører profilen.

Agenter arver en brugersession, dæmoner gør ikke

Apples launchd-dokumentation adskiller agenter pr. bruger fra systemdæmoner. En agent kører i den loggede brugers kontekst med dennes nøglering og miljø. En dæmon kører uden den session, og at flytte et job til en systemmappe genskaber ikke brugerens interaktive legitimationsoplysninger.

Den sondring bestemmer designet. Hvis forbindelsen kræver, at en person logger ind eller godkender en MFA-anmodning, er den understøttede løsning et job i brugersessionen, der kører efter login. Hvis det skal fungere uden nogen logget ind, har klienten brug for en godkendt uovervåget identitet med sin egen fornyelses- og tilbagekaldelsesproces. Vælger man den forkerte række, får man et job, der starter rent og fejler ved det første godkendelsestrin.

Tildæk ikke forskellen med en adgangskode i argumentarrayet eller ved at slå certifikatkontroller fra. Begge gør et godkendelseskrav til en permanent hemmelighed i en læsbar fil, og den anden betyder, at tunnelen godkender alt, der svarer.

Overvågning virker kun, hvis processen bliver i forgrunden

En klient, der selv gør sig til dæmon, giver straks kontrollen tilbage til launchd, og supervisor ser så på en proces, der allerede er afsluttet. Tunnelen kan være oppe, men launchd tror, jobbet fejlede, og dens genstartspolitik vil gøre noget, du ikke havde til hensigt.

Brug klientens dokumenterede forgrunds- eller tjenestetilstand. Hvis produktet har sin egen understøttede opstartsfunktion, ved den allerede, hvordan man bliver i forgrunden, og hvordan man overlader til netværksstakken; et brugerdefineret job er et separat design, ikke en forbedring af det.

Giv jobbet en unik etiket, den tilsigtede eksekverbare fil og et bevidst argumentarray. Et array er ikke en shell-kommandolinje, så rør og omdirigeringer virker ikke der, og citater opfører sig anderledes. En kommando, der lykkes i en administrators terminal, er i bedste fald en foreløbig kontrol.

Legitimationsoplysninger skal virke uden en prompt

Uovervåget drift flytter legitimationsproblemet i stedet for at fjerne det. Nogen skal eje identiteten, beslutte, hvor længe den lever, og dokumentere, hvordan den udskiftes. Et certifikat uden overvågning af udløb bliver et udfald med en dato i kalenderen.

Hold hemmeligheder ude af argumenter og ude af jobbets standardoutput. Hvis klienten understøtter at læse en legitimationsoplysning fra et beskyttet lager, brug den vej, og kontroller, at jobbets eksekveringskontekst kan nå lageret. En dæmon, der kører som root, kan normalt ikke læse et element fra login-nøgleringen, og det er den slags detalje, der kun dukker op i systemkonteksten.

Definer, hvad parathed betyder, og test det der

En vellykket start beviser, at processen startede. Det beviser ikke, at netværket er oppe, at gatewayen accepterede identiteten, eller at den private applikation kan nås. Hvis noget andet afhænger af tunnelen, har det brug for et parathedssignal, der afspejler forbindelsen, ikke jobbets starttid.

Gentagelser skal være begrænsede og skelne et manglende netværk fra en afvist legitimationsoplysning. Genstart ved hver fejl kan ikke reparere et udløbet certifikat og producerer en log fuld af identiske forsøg, der skjuler det rigtige.

Accepter jobbet i den kontekst, det faktisk skal køre i: intet netværk ved opstart, et normalt login, en opvågning fra dvale og et kontrolleret stop. Noter derefter jobetikette, klientversion og profilrevision sammen, så den næste person arver en tjeneste, der kan henføres, i stedet for en fil, der engang virkede.