VPN pe Mac la pornire: launchd supraveghează sarcina, nu tunelul

Sarcina rulează la autentificare, jurnalul arată clientul pornind, dar tunelul nu se ridică niciodată. Sau se ridică și dispare câteva secunde mai târziu. În ambele cazuri lista de proprietăți era probabil în regulă. launchd a făcut două promisiuni când a acceptat sarcina: va supraveghea un proces, iar acel proces va continua să ruleze. VPN-ul are nevoie de ambele, iar un fișier XML corect nu oferă niciuna.

O listă de proprietăți validă nu este un serviciu funcțional

plutil -lint verifică structura. Nu poate spune dacă binarul există, dacă argumentele sunt acceptate de această versiune a clientului sau dacă sarcina pornește într-un context în care acreditările sunt disponibile. Sunt întrebări semantice și explică majoritatea eșecurilor care arată ca probleme ale launchd.

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

Citește ieșirea celei de-a doua comenzi în loc să presupui că sarcina a fost încărcată. Aceasta raportează ultimul status de ieșire și dacă serviciul rulează, ceea ce distinge „nu a pornit niciodată” de „a pornit și a murit” înainte de a atinge profilul.

Agenții moștenesc o sesiune de utilizator, demonii nu

Documentația Apple despre launchd separă agenții fiecărui utilizator de demonii de sistem. Un agent rulează în contextul utilizatorului autentificat, cu brelocul și mediul acelui utilizator. Un demon rulează fără acea sesiune, iar mutarea unei sarcini într-un director de sistem nu recreează acreditările interactive ale utilizatorului.

Această diferență decide proiectarea. Dacă conexiunea cere ca o persoană să se autentifice sau să aprobe o solicitare MFA, aranjamentul acceptat este o sarcină în sesiunea utilizatorului care rulează după autentificare. Dacă trebuie să funcționeze fără nimeni autentificat, clientul are nevoie de o identitate nesupravegheată aprobată, cu propriul proces de reînnoire și revocare. Alegerea rândului greșit produce o sarcină care pornește curat și eșuează la primul pas de autentificare.

Nu masca diferența cu o parolă în tabloul de argumente sau dezactivând verificările certificatelor. Ambele transformă o cerință de autentificare într-un secret permanent într-un fișier lizibil, iar a doua înseamnă că tunelul autentifică tot ce răspunde.

Supravegherea funcționează doar dacă procesul rămâne în față

Un client care se transformă singur în demon returnează imediat controlul către launchd, iar supraveghetorul urmărește apoi un proces care s-a încheiat deja. Tunelul poate fi activ, dar launchd consideră că sarcina a eșuat, iar politica sa de repornire va face ceva ce nu ai intenționat.

Folosește modul documentat de prim-plan sau de serviciu al clientului. Dacă produsul are propria funcție de pornire acceptată, acea funcție știe deja cum să rămână în prim-plan și cum să predea stiva de rețea; o sarcină personalizată este un proiect separat, nu o îmbunătățire a ei.

Dă sarcinii o etichetă unică, executabilul dorit și un tablou de argumente deliberat. Un tablou nu este o linie de comandă shell, așa că conductele și redirecționările nu funcționează acolo, iar ghilimelele se comportă diferit. O comandă care reușește în terminalul unui administrator este cel mult o verificare preliminară.

Acreditările trebuie să funcționeze fără solicitare

Operarea nesupravegheată mută problema acreditărilor în loc să o elimine. Cineva trebuie să dețină identitatea, să decidă cât trăiește și să documenteze cum este înlocuită. Un certificat fără monitorizarea expirării devine o întrerupere cu o dată în calendar.

Ține secretele în afara argumentelor și în afara ieșirii standard a sarcinii. Dacă clientul acceptă citirea unei acreditări dintr-un depozit protejat, folosește acea cale și verifică dacă contextul de execuție al sarcinii poate ajunge la depozit. Un demon care rulează ca root de obicei nu poate citi un element din brelocul de autentificare, iar acesta este genul de detaliu care apare doar în contextul de sistem.

Definește ce înseamnă pregătit și testează acolo

O lansare reușită dovedește că procesul a pornit. Nu dovedește că rețeaua este activă, că gateway-ul a acceptat identitatea sau că aplicația privată este accesibilă. Dacă altceva depinde de tunel, are nevoie de un semnal de pregătire care reflectă conexiunea, nu de ora de pornire a sarcinii.

Reîncercările trebuie să fie limitate și să distingă o rețea lipsă de o acreditare respinsă. Repornirea la fiecare eșec nu poate repara un certificat expirat și produce un jurnal plin de încercări identice care o ascunde pe cea reală.

Acceptă sarcina în contextul în care va rula de fapt: fără rețea la pornire, o autentificare normală, o trezire din repaus și o oprire controlată. Apoi notează împreună eticheta sarcinii, versiunea clientului și revizia profilului, ca următoarea persoană să moștenească un serviciu atribuibil în locul unui fișier care a funcționat cândva.