Mac VPN indításkor: a launchd a feladatot felügyeli, nem az alagutat

A feladat bejelentkezéskor fut, a napló mutatja a kliens indulását, az alagút mégsem jön létre. Vagy létrejön, és néhány másodperc múlva eltűnik. Mindkét esetben a tulajdonságlista valószínűleg rendben volt. launchd két ígéretet tett, amikor elfogadta a feladatot: felügyelni fog egy folyamatot, és az a folyamat futni fog. A VPN-nek mindkettőre szüksége van, és egy helyes XML-fájl egyiket sem nyújtja.

Az érvényes tulajdonságlista nem működő szolgáltatás

plutil -lint a szerkezetet ellenőrzi. Nem tudja megmondani, létezik-e a bináris, támogatja-e ezt a kliensverzió az argumentumokat, vagy a feladat olyan környezetben indul-e, ahol a hitelesítő adatok elérhetők. Ezek szemantikai kérdések, és a legtöbb olyan hibát megmagyarázzák, amely launchd-problémának tűnik.

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

Olvassa el a második parancs kimenetét, ahelyett hogy feltételezné, a feladat betöltődött. Jelzi az utolsó kilépési állapotot és azt, hogy fut-e a szolgáltatás, ami megkülönbözteti a „soha nem indult el” és az „elindult és meghalt” esetet, mielőtt a profilhoz nyúlna.

Az ügynökök felhasználói munkamenetet örökölnek, a démonok nem

Az Apple launchd-dokumentációja elválasztja a felhasználónkénti ügynököket a rendszerdémonoktól. Az ügynök a bejelentkezett felhasználó környezetében fut, annak kulcskarikájával és környezetével. A démon e munkamenet nélkül fut, és egy feladat rendszerkönyvtárba helyezése nem hozza újra létre a felhasználó interaktív hitelesítő adatait.

Ez a különbség dönti el a tervezést. Ha a kapcsolat megköveteli, hogy egy személy bejelentkezzen vagy jóváhagyjon egy MFA-kérést, a támogatott elrendezés egy felhasználói munkamenetben futó feladat, amely bejelentkezés után indul. Ha senki bejelentkezése nélkül kell működnie, a kliensnek jóváhagyott, felügyelet nélküli identitásra van szüksége, saját megújítási és visszavonási folyamattal. A rossz sor választása olyan feladatot eredményez, amely tisztán indul, és az első hitelesítési lépésnél elbukik.

Ne takarja el a különbséget jelszóval az argumentumtömbben vagy a tanúsítványellenőrzések kikapcsolásával. Mindkettő állandó titokká teszi a hitelesítési követelményt egy olvasható fájlban, a második pedig azt jelenti, hogy az alagút mindent hitelesít, ami válaszol.

A felügyelet csak akkor működik, ha a folyamat elöl marad

Az a kliens, amely magát démonná alakítja, azonnal visszaadja az irányítást a launchd-nek, a felügyelő pedig egy már kilépett folyamatot figyel. Az alagút lehet, hogy áll, de a launchd sikertelennek hiszi a feladatot, és az újraindítási szabályzata olyasmit tesz, amit nem szándékozott.

Használja a kliens dokumentált előtér- vagy szolgáltatásmódját. Ha a terméknek saját támogatott indítási funkciója van, az már tudja, hogyan maradjon előtérben, és hogyan adja át a hálózati veremnek; az egyedi feladat külön tervezés, nem annak javítása.

Adjon a feladatnak egyedi címkét, a szándékolt futtatható fájlt és átgondolt argumentumtömböt. A tömb nem shell-parancssor, ezért a csövek és az átirányítások nem működnek benne, az idézőjelek pedig másképp viselkednek. Az a parancs, amely egy rendszergazda termináljában sikerül, legfeljebb előzetes ellenőrzés.

A hitelesítő adatoknak kérés nélkül kell működniük

A felügyelet nélküli működés elmozdítja a hitelesítő adatok problémáját ahelyett, hogy megszüntetné. Valakinek birtokolnia kell az identitást, eldöntenie, meddig él, és dokumentálnia, hogyan cserélik le. A lejárat figyelése nélküli tanúsítvány kimaradássá válik, amelynek dátuma van a naptárban.

Tartsa a titkokat az argumentumokon és a feladat szabványos kimenetén kívül. Ha a kliens támogatja a hitelesítő adat védett tárolóból való olvasását, használja azt az utat, és ellenőrizze, hogy a feladat végrehajtási környezete eléri a tárolót. A rootként futó démon általában nem tudja olvasni a bejelentkezési kulcskarika elemét, és ez az a részlet, amely csak a rendszerkörnyezetben bukkan fel.

Határozza meg, mit jelent a készültség, majd ott tesztelje

A sikeres indítás azt bizonyítja, hogy a folyamat elkezdődött. Nem bizonyítja, hogy a hálózat áll, hogy az átjáró elfogadta az identitást, vagy hogy a magánalkalmazás elérhető. Ha valami más függ az alagúttól, olyan készültségi jelre van szüksége, amely a kapcsolatot tükrözi, nem a feladat kezdési idejét.

Az újrapróbálkozásoknak korlátozottaknak kell lenniük, és meg kell különböztetniük a hiányzó hálózatot az elutasított hitelesítő adattól. Az újraindítás minden hiba esetén nem tudja megjavítani a lejárt tanúsítványt, és azonos kísérletekkel teli naplót hoz létre, amely elrejti az igazit.

Fogadja el a feladatot abban a környezetben, amelyben valóban futni fog: hálózat nélkül indításkor, normál bejelentkezéssel, alvásból ébredve és ellenőrzött leállítással. Utána rögzítse együtt a feladat címkéjét, a kliensverziót és a profil revízióját, hogy a következő ember egy hozzárendelhető szolgáltatást örököljön egy egykor működő fájl helyett.