VPN prima dell'accesso su macOS: sblocco, finestra di login, sessione
Lo sblocco di FileVault, la finestra di login e la sessione utente sono fasi separate. Un client desktop che parte al login risolve solo l'ultima.
Ecco una convinzione che costa una settimana: che un Mac abbia un solo momento chiamato prima del login e che un client VPN o parta allora o no. La macchina ha in realtà almeno tre momenti in cui l'accesso alla rete conta, separati da chi può detenere credenziali in quel punto. Un client avviato da un elemento di login copre esattamente uno di essi, ed è l'ultimo.
Il mito che un'impostazione copra l'intero avvio
Rileggete la pagina del prodotto e cercate quale fase nomina la funzione. Una casella etichettata avvia al login significa un elemento di login, che viene eseguito dopo che esiste una sessione utente. Una casella etichettata connetti su richiesta significa che il client apre una connessione quando il traffico corrisponde a una regola, il che richiede comunque che il client e le sue credenziali siano disponibili.
Nessuna delle due raggiunge il processo di avvio. Non è un limite che il fornitore ha dimenticato di rimuovere; è ciò che il sistema operativo consente. Prima che il volume venga sbloccato non esiste un sistema in esecuzione da cui avviare un client, e dopo il logout i segreti dell'utente se ne vanno con la sessione. Due muri separati, e nessuno cede a un'altra casella.
Una volta separate le fasi, la domanda originale cambia forma. Invece di chiedere se la VPN parte prima del login, chiedete quale dei tre momenti specifici deve funzionare, e poi scoprite che ognuno ha un proprietario diverso: lo stack di cifratura, l'estensione di rete o la sessione utente.
Cosa succede davvero in ogni fase
L'avvio inizia con un volume cifrato che va sbloccato prima che esista un sistema utilizzabile per qualunque scopo generale. Quello sblocco avviene in un contesto ristretto con un insieme ristretto di credenziali, e Apple documenta chiaramente che i dati cifrati restano inaccessibili senza uno sblocco valido.
Poi arriva la finestra di login, dove il sistema è in esecuzione ma non esiste ancora alcuna sessione utente. Un'estensione in contesto utente è già terminata se l'utente ha chiuso la sessione, e un'estensione globale di sistema può essere ancora in esecuzione, ma essere in esecuzione non è lo stesso che detenere le credenziali di cui ha bisogno la vostra VPN.
Poi arriva la sessione, dove un client normale può leggere il portachiavi di login, chiedere un secondo fattore e applicare le rotte spinte. La maggior parte delle funzioni che le persone descrivono come prima del login sono in realtà questa fase, attivata all'inizio della sessione e non prima.
| Stage | What it can use | What it cannot do |
|---|---|---|
| FileVault unlock | Credentials supplied at the console to unlock the volume | Run an ordinary VPN app or read a user keychain |
| Login window | System context, possibly a joined network | Use a user secret that only exists after login |
| User session | Login keychain, interactive MFA, full client features | Exist before the volume unlocks |
Perché un launch daemon non può accedere per un utente assente
Il privilegio elevato sembra dover risolvere il problema, e non lo fa. Un launch daemon viene eseguito come processo di sistema senza alcuna sessione utente alle spalle, quindi non c'è portachiavi da sbloccare e nessuna persona che risponda a una richiesta. Può aprire un socket e leggere un file; ciò che non può fare è diventare l'utente che possiede le credenziali. Il privilegio non è identità, e questo è esattamente il punto in cui i due si confondono.
Ciò che le persone costruiscono in quel vuoto è uno script con dentro una password, che è un problema peggiore di quello da cui erano partite.
La versione onesta del requisito è più stretta. Se la macchina deve raggiungere una risorsa protetta mentre nessuno è presente, l'identità che quella risorsa accetta deve essere una che la macchina possa mantenere senza una persona: un certificato di dispositivo, una credenziale nel portachiavi di sistema o un account il cui secondo fattore non sia una notifica push a un telefono nella tasca di qualcuno. Progettate quell'identità di proposito, e la domanda della fase di solito si risponde da sola.
La funzione Windows prima del login non si trasferisce
Windows ha un meccanismo documentato di accesso prima del login per alcuni prodotti di accesso remoto, e il nome viaggia meglio della capacità. Una funzione descritta in una guida al deployment di Windows non vi dice nulla se lo stesso fornitore implementi un equivalente su macOS.
Chiedete una dichiarazione che copra l'hardware del Mac, la versione di macOS, la versione del client e il metodo di autenticazione che usate davvero. Un'affermazione generica di supporto non basta, perché la differenza tra funzionante e non funzionante sta spesso in uno di quei quattro.
Se il fornitore non sa rispondere, questa è la risposta. Pianificate la fase della sessione e progettate un'alternativa per il caso senza supervisione, invece di scoprire il vuoto durante un rollout.
Cosa chiedere invece
Scrivete il requisito nella lingua delle fasi. Quale risorsa, necessaria a chi, in quale contesto e con quale ritardo accettabile quando la connessione non c'è ancora?
Se la risposta è un utente che accede e poi ha bisogno del tunnel, connetti su richiesta e un elemento di avvio bastano e costano poco. Se la risposta è una macchina che si riavvia di notte e deve fare rapporto, la progettazione ha bisogno di un percorso di sblocco del disco supportato, un'identità di dispositivo e un processo di ripristino che funzioni quando la rete non si alza mai. Se la risposta è l'accesso dell'organizzazione che dipende dal tunnel, allora i progetti di login, identità e VPN vanno costruiti insieme e non comprati separatamente.
La documentazione FileVault di Apple è il punto di partenza giusto per la fase di sblocco. Tutto ciò che segue è una questione di client e identità che una dichiarazione del fornitore dovrebbe risolvere prima dell'acquisto.