VPN abans de l'inici de sessió al macOS: desbloqueig, finestra d'inici i sessió

Hi ha una creça que costa una setmana a qui la té: que un Mac té un sol moment anomenat abans de l'inici de sessió i que un client VPN o bé arrenca llavors o bé no arrenca. En realitat, la màquina té com a mínim tres moments en què l'accés a la xarxa és important, separats per qui pot tenir credencials en aquell punt. Un client llançat des d'un element d'inici de sessió cobreix exactament un d'ells, i és l'últim.

El mite que una sola opció cobreix tota l'engegada

Torna a llegir la pàgina del producte i mira quina etapa nomena la funció. Una casella amb l'etiqueta inicia en l'inici de sessió vol dir un element d'inici de sessió, que s'executa després que existeixi una sessió d'usuari. Una casella amb l'etiqueta connecta quan cal vol dir que el client obre una connexió quan el trànsit coincideix amb una regla, cosa que encara exigeix que el client i les seves credencials estiguin disponibles.

Cap de les dues arriba al procés d'engegada. No és una limitació que el proveïdor s'hagi oblidat de treure; és el que permet el sistema operatiu. Abans que el volum es desbloquegi no hi ha cap sistema en marxa des del qual llançar un client, i després de tancar la sessió els secrets de l'usuari marxen amb la sessió. Dues parets separades, i cap de les dues cedeix davant d'una altra casella.

Quan separen les etapes, la pregunta original canvia de forma. En lloc de preguntar si la VPN arrenca abans de l'inici de sessió, preguntes quin dels tres moments concrets ha de funcionar, i llavors descobreixes que cada un té un propietari diferent: la pila de xifratge, l'extensió de xarxa o la sessió d'usuari.

Què passa realment a cada etapa

L'engegada comença amb un volum xifrat que s'ha de desbloquejar abans que hi hagi un sistema utilitzable per fer qualsevol cosa d'ús general. Aquest desbloqueig passa en un context restringit amb un conjunt restringit de credencials, i Apple documenta clarament que les dades xifrades continuen inaccessibles sense un desbloqueig vàlid.

Després ve la finestra d'inici de sessió, on el sistema funciona però encara no existeix cap sessió d'usuari. Una extensió en context d'usuari ja ha acabat si l'usuari ha tancat la sessió, i una extensió global del sistema pot continuar en marxa, però funcionar no és el mateix que tenir les credencials que necessita la teva VPN.

Després ve la sessió, on un client normal pot llegir el clauer d'inici de sessió, demanar un segon factor i aplicar les rutes empenyudes. La majoria de funcions que la gent descriu com a abans de l'inici de sessió són en realitat aquesta etapa, activada al principi de la sessió i no abans.

Per què un launch daemon no pot iniciar sessió per un usuari absent

El privilegi elevat sembla que hauria de resoldre el problema, i no ho fa. Un launch daemon s'executa com a procés del sistema sense cap sessió d'usuari al darrere, així que no hi ha clauer per desbloquejar ni cap persona per respondre a una sol·licitud. Pot obrir un sòcol i llegir un fitxer; el que no pot fer és convertir-se en l'usuari que posseeix les credencials. El privilegi no és identitat, i aquest és exactament el punt on les dues coses es confonen.

El que la gent construeix en aquest buit és un script amb una contrasenya a dins, que és un problema pitjor que el que tenien al principi.

La versió honesta del requisit és més estreta. Si la màquina ha d'arribar a un recurs protegit mentre no hi ha ningú, la identitat que aquest recurs accepta ha de ser una que la màquina pugui mantenir sense una persona: un certificat de dispositiu, una credencial al clauer del sistema o un compte el segon factor del qual no sigui una notificació push a un telèfon a la butxaca d'algú. Dissenya aquesta identitat deliberadament, i la pregunta de l'etapa normalment es respon sola.

La funció de Windows abans de l'inici de sessió no es trasllada

Windows té un mecanisme documentat d'accés abans de l'inici de sessió per a alguns productes d'accés remot, i el nom viatja millor que la capacitat. Una funció descrita en una guia de desplegament de Windows no et diu res sobre si el mateix proveïdor implementa un equivalent al macOS.

Demana una declaració que cobreixi el maquinari del Mac, la versió de macOS, la versió del client i el mètode d'autenticació que realment utilitzes. Una afirmació general de suport no n'hi ha prou, perquè la diferència entre funcionar i no funcionar sovint es troba en un d'aquests quatre.

Si el proveïdor no pot respondre, aquesta és la resposta. Planifica l'etapa de la sessió i dissenya una alternativa per al cas sense assistència, en lloc de descobrir el buit durant un desplegament.

Què demanar enlloc d'això

Escriu el requisit en el llenguatge de les etapes. Quin recurs, necessitat per qui, en quin context i amb quin retard acceptable quan la connexió encara no hi és?

Si la resposta és un usuari que inicia sessió i després necessita el túnel, la connexió quan cal i un element d'inici són suficients i barats. Si la resposta és una màquina que es reinicia de nit i ha de fer l'informe, el disseny necessita un camí de desbloqueig del disc suportat, una identitat de dispositiu i un procés de recuperació que funcioni quan la xarxa no apareix mai. Si la resposta és l'inici de sessió d'organització que depèn del túnel, llavors els dissenys d'inici de sessió, identitat i VPN s'han de construir junts en lloc de comprar-se per separat.

La documentació de FileVault d'Apple és el punt de partida correcte per a l'etapa de desbloqueig. Tot el que ve després és una qüestió de client i identitat que una declaració del proveïdor hauria de resoldre abans que compris.