VPN antes do inicio de sesión en macOS: desbloqueo, xanela de inicio e sesión
O desbloqueo de FileVault, a xanela de inicio de sesión e a sesión de usuario son etapas separadas. Un cliente de escritorio que arrinca ao iniciar sesión só resolve a última.
Velaquí unha crenza que lle custa unha semana a quen a ten: que un Mac ten un único momento chamado antes do inicio de sesión e que un cliente VPN ou arrinca entón ou non arrinca. En realidade, a máquina ten polo menos tres momentos nos que o acceso á rede importa, separados por quen pode ter credenciais nese punto. Un cliente lanzado desde un elemento de inicio de sesión cobre exactamente un deles, e é o último.
O mito de que unha soa opción cobre todo o arranque
Volva ler a páxina do produto e busque que etapa nomea a función. Unha caixa etiquetada iniciar ao iniciar sesión significa un elemento de inicio de sesión, que se executa despois de que exista unha sesión de usuario. Unha caixa etiquetada conectar cando sexa necesario significa que o cliente abre unha conexión cando o tráfico coincide cunha regra, o que aínda esixe que o cliente e as súas credenciais estean dispoñibles.
Ningunha das dúas chega ao proceso de arranque. Non é unha limitación que o provedor esquecera eliminar; é o que permite o sistema operativo. Antes de que se desbloquee o volume non hai un sistema en execución desde o que lanzar un cliente, e tras pechar a sesión os segredos do usuario van coa sesión. Dous muros separados, e ningún cede ante outra caixa.
Cando separa as etapas, a pregunta orixinal cambia de forma. En lugar de preguntar se a VPN arrinca antes do inicio de sesión, pregunta cal de tres momentos concretos ten que funcionar, e entón descobre que cada un ten un dono distinto: a pila de cifrado, a extensión de rede ou a sesión de usuario.
Que ocorre realmente en cada etapa
O arranque comeza cun volume cifrado que hai que desbloquear antes de que exista un sistema utilizábel para calquera cousa de propósito xeral. Ese desbloqueo ocorre nun contexto restrinxido cun conxunto restrinxido de credenciais, e Apple documenta con claridade que os datos cifrados seguen inaccesíbeis sen un desbloqueo válido.
Despois vén a xanela de inicio de sesión, onde o sistema funciona pero aínda non existe ningunha sesión de usuario. Unha extensión en contexto de usuario xa rematou se o usuario pechou a sesión, e unha extensión global do sistema pode seguir executándose, pero executarse non é o mesmo que ter as credenciais que necesita a súa VPN.
Logo vén a sesión, onde un cliente normal pode ler o chaveiro de inicio de sesión, pedir un segundo factor e aplicar as rutas empurradas. A maioría das funcións que a xente describe como antes do inicio de sesión son en realidade esta etapa, activada ao principio da sesión e non antes.
| 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 |
Por que un launch daemon non pode iniciar sesión por un usuario ausente
O privilexio elevado parece que debería resolver o problema, e non o fai. Un launch daemon execútase como proceso do sistema sen ningunha sesión de usuario detrás, así que non hai chaveiro que desbloquear nin persoa que responda a unha solicitude. Pode abrir un socket e ler un ficheiro; o que non pode é converterse no usuario que posúe as credenciais. O privilexio non é identidade, e este é exactamente o punto onde ambas se confunden.
O que a xente constrúe nese oco é un script cun contrasinal dentro, que é un problema peor que o que tiñan ao principio.
A versión honesta do requisito é máis estreita. Se a máquina ten que alcanzar un recurso protexido mentres non hai ninguén, a identidade que ese recurso acepta ten que ser unha que a máquina poida manter sen unha persoa: un certificado de dispositivo, unha credencial no chaveiro do sistema ou unha conta cuxo segundo factor non sexa unha notificación push a un teléfono no peto de alguén. Deseñe esa identidade a propósito, e a pregunta da etapa adoita responderse soa.
A función de Windows anterior ao inicio de sesión non se traslada
Windows ten un mecanismo documentado de acceso antes do inicio de sesión para algúns produtos de acceso remoto, e o nome viaxa mellor ca a capacidade. Unha función descrita nunha guía de despregamento de Windows non lle di nada sobre se o mesmo provedor implementa un equivalente en macOS.
Pida unha declaración que cubra o hardware do Mac, a versión de macOS, a versión do cliente e o método de autenticación que realmente usa. Unha afirmación xeral de compatibilidade non abonda, porque a diferenza entre funcionar e non funcionar adoita estar nun deses catro.
Se o provedor non pode responder, esa é a resposta. Planifique a etapa da sesión e deseñe unha alternativa para o caso sen asistencia, en lugar de descubrir o oco durante un despregamento.
Que pedir no seu lugar
Escriba o requisito na linguaxe das etapas. Que recurso, necesario para quen, en que contexto e con que atraso aceptábel cando a conexión aínda non está?
Se a resposta é un usuario que inicia sesión e despois necesita o túnel, a conexión cando sexa necesario e un elemento de arranque son suficientes e baratos. Se a resposta é unha máquina que se reinicia de noite e ten que informar, o deseño necesita un camiño de desbloqueo do disco compatíbel, unha identidade de dispositivo e un proceso de recuperación que funcione cando a rede nunca aparece. Se a resposta é o inicio de sesión da organización que depende do túnel, entón os deseños de inicio de sesión, identidade e VPN teñen que construírse xuntos en lugar de comprarse por separado.
A documentación de FileVault de Apple é o punto de partida correcto para a etapa de desbloqueo. Todo o que vén despois é unha cuestión de cliente e identidade que unha declaración do provedor debería resolver antes de comprar.