VPN antes del inicio de sesión en macOS: desbloqueo, ventana de inicio y sesión

Hay una creencia que cuesta una semana a quien la tiene: que un Mac tiene un único momento llamado antes del inicio de sesión y que un cliente VPN o arranca entonces o no arranca. En realidad, la máquina tiene al menos tres momentos en los que el acceso a la red importa, separados por quién puede tener credenciales en ese punto. Un cliente lanzado desde un ítem de inicio de sesión cubre exactamente uno de ellos, y es el último.

El mito de que una sola opción cubre todo el arranque

Vuelve a leer la página del producto y busca qué etapa nombra la función. Una casilla etiquetada iniciar al iniciar sesión significa un ítem de inicio de sesión, que se ejecuta después de que exista una sesión de usuario. Una casilla etiquetada conectar cuando sea necesario significa que el cliente abre una conexión cuando el tráfico coincide con una regla, lo que sigue exigiendo que el cliente y sus credenciales estén disponibles.

Ninguna de las dos llega al proceso de arranque. No es una limitación que el proveedor haya olvidado eliminar; es lo que permite el sistema operativo. Antes de que se desbloquee el volumen no hay un sistema en ejecución desde el que lanzar un cliente, y tras cerrar sesión los secretos del usuario se van con la sesión. Dos muros separados, y ninguno cede ante otra casilla.

Cuando separas las etapas, la pregunta original cambia de forma. En lugar de preguntar si la VPN arranca antes del inicio de sesión, preguntas cuál de tres momentos concretos tiene que funcionar, y entonces descubres que cada uno tiene un dueño distinto: la pila de cifrado, la extensión de red o la sesión de usuario.

Qué ocurre realmente en cada etapa

El arranque comienza con un volumen cifrado que hay que desbloquear antes de que exista un sistema utilizable para cualquier cosa de propósito general. Ese desbloqueo ocurre en un contexto restringido con un conjunto restringido de credenciales, y Apple documenta con claridad que los datos cifrados siguen inaccesibles sin un desbloqueo válido.

Después viene la ventana de inicio de sesión, donde el sistema funciona pero aún no existe ninguna sesión de usuario. Una extensión en contexto de usuario ya ha terminado si el usuario cerró sesión, y una extensión global del sistema puede seguir ejecutándose, pero ejecutarse no es lo mismo que tener las credenciales que necesita tu VPN.

Luego viene la sesión, donde un cliente normal puede leer el llavero de inicio de sesión, pedir un segundo factor y aplicar las rutas empujadas. La mayoría de las funciones que la gente describe como antes del inicio de sesión son en realidad esta etapa, activada al principio de la sesión y no antes.

Por qué un launch daemon no puede iniciar sesión por un usuario ausente

El privilegio elevado parece que debería resolver el problema, y no lo hace. Un launch daemon se ejecuta como proceso del sistema sin ninguna sesión de usuario detrás, así que no hay llavero que desbloquear ni persona que responda a una solicitud. Puede abrir un socket y leer un archivo; lo que no puede es convertirse en el usuario que posee las credenciales. El privilegio no es identidad, y este es exactamente el punto donde ambas se confunden.

Lo que la gente construye en ese hueco es un script con una contraseña dentro, que es un problema peor que el que tenían al principio.

La versión honesta del requisito es más estrecha. Si la máquina tiene que alcanzar un recurso protegido mientras no hay nadie, la identidad que ese recurso acepta tiene que ser una que la máquina pueda mantener sin una persona: un certificado de dispositivo, una credencial en el llavero del sistema o una cuenta cuyo segundo factor no sea una notificación push a un teléfono en el bolsillo de alguien. Diseña esa identidad a propósito, y la pregunta de la etapa suele responderse sola.

La función de Windows anterior al inicio de sesión no se traslada

Windows tiene un mecanismo documentado de acceso antes del inicio de sesión para algunos productos de acceso remoto, y el nombre viaja mejor que la capacidad. Una función descrita en una guía de despliegue de Windows no te dice nada sobre si el mismo proveedor implementa un equivalente en macOS.

Pide una declaración que cubra el hardware del Mac, la versión de macOS, la versión del cliente y el método de autenticación que realmente usas. Una afirmación general de compatibilidad no basta, porque la diferencia entre funcionar y no funcionar suele estar en uno de esos cuatro.

Si el proveedor no puede responder, esa es la respuesta. Planifica la etapa de la sesión y diseña una alternativa para el caso sin asistencia, en lugar de descubrir el hueco durante un despliegue.

Qué pedir en su lugar

Escribe el requisito en el lenguaje de las etapas. ¿Qué recurso, necesario para quién, en qué contexto y con qué retraso aceptable cuando la conexión todavía no está?

Si la respuesta es un usuario que inicia sesión y luego necesita el túnel, la conexión cuando sea necesario y un ítem de arranque son suficientes y baratos. Si la respuesta es una máquina que se reinicia de noche y tiene que reportar, el diseño necesita una ruta de desbloqueo del disco compatible, una identidad de dispositivo y un proceso de recuperación que funcione cuando la red nunca aparece. Si la respuesta es el inicio de sesión de la organización que depende del túnel, entonces los diseños de inicio de sesión, identidad y VPN tienen que construirse juntos en lugar de comprarse por separado.

La documentación de FileVault de Apple es el punto de partida correcto para la etapa de desbloqueo. Todo lo que viene después es una cuestión de cliente e identidad que una declaración del proveedor debería resolver antes de comprar.