VPN de Mac al arrancar: launchd supervisa la tarea, no el túnel

La tarea se ejecuta al iniciar sesión, el registro muestra que el cliente arranca y el túnel nunca sube. O sube y desaparece unos segundos después. En ambos casos la lista de propiedades probablemente estaba bien. launchd hizo dos promesas cuando aceptó la tarea: supervisará un proceso y ese proceso seguirá ejecutándose. La VPN necesita ambas, y un archivo XML correcto no ofrece ninguna.

Una lista de propiedades válida no es un servicio en funcionamiento

plutil -lint comprueba la estructura. No puede decirle si el binario existe, si los argumentos son compatibles con esta versión del cliente o si la tarea arranca en un contexto donde las credenciales están disponibles. Son preguntas semánticas y explican la mayoría de los fallos que parecen problemas de launchd.

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

Lea la salida del segundo comando en lugar de suponer que la tarea se cargó. Informa del último estado de salida y de si el servicio se ejecuta, lo que distingue “nunca arrancó” de “arrancó y murió” antes de tocar el perfil.

Los agentes heredan una sesión de usuario, los demonios no

La documentación de launchd de Apple separa los agentes por usuario de los demonios del sistema. Un agente se ejecuta en el contexto del usuario conectado, con su llavero y su entorno. Un demonio se ejecuta sin esa sesión, y trasladar una tarea a un directorio del sistema no recrea las credenciales interactivas del usuario.

Esa distinción decide el diseño. Si la conexión exige que una persona inicie sesión o apruebe una solicitud MFA, la disposición admitida es una tarea en la sesión del usuario que se ejecuta tras el inicio de sesión. Si debe funcionar sin nadie conectado, el cliente necesita una identidad aprobada sin supervisión con su propio proceso de renovación y revocación. Elegir la fila equivocada produce una tarea que arranca limpia y falla en el primer paso de autenticación.

No disimule la diferencia con una contraseña en la matriz de argumentos ni desactivando las comprobaciones de certificado. Ambas convierten un requisito de autenticación en un secreto permanente en un archivo legible, y la segunda significa que el túnel autentica cualquier cosa que responda.

La supervisión solo funciona si el proceso se queda delante

Un cliente que se convierte a sí mismo en demonio devuelve el control a launchd de inmediato, y el supervisor observa entonces un proceso que ya ha salido. El túnel puede estar arriba, pero launchd cree que la tarea falló y su política de reinicio hará algo que usted no pretendía.

Utilice el modo de primer plano o de servicio documentado del cliente. Si el producto tiene su propia función de arranque compatible, ya sabe cómo permanecer en primer plano y cómo ceder el paso a la pila de red; una tarea personalizada es un diseño aparte, no una mejora de eso.

Dé a la tarea una etiqueta única, el ejecutable previsto y una matriz de argumentos deliberada. Una matriz no es una línea de comandos de shell, así que las tuberías y las redirecciones no funcionan allí, y las comillas se comportan de otro modo. Un comando que triunfa en la terminal de un administrador es, como mucho, una comprobación preliminar.

Las credenciales tienen que funcionar sin petición

El funcionamiento sin supervisión traslada el problema de las credenciales en vez de eliminarlo. Alguien debe poseer la identidad, decidir cuánto vive y documentar cómo se sustituye. Un certificado sin seguimiento de caducidad se convierte en una interrupción con fecha en el calendario.

Mantenga los secretos fuera de los argumentos y de la salida estándar de la tarea. Si el cliente admite leer una credencial de un almacén protegido, use esa vía y compruebe que el contexto de ejecución de la tarea llega al almacén. Un demonio que se ejecuta como root normalmente no puede leer un elemento del llavero de inicio de sesión, y ese es el tipo de detalle que solo aparece en el contexto del sistema.

Defina qué significa estar listo y pruébelo allí

Un arranque correcto demuestra que el proceso comenzó. No demuestra que la red esté activa, que la puerta de enlace haya aceptado la identidad ni que la aplicación privada sea accesible. Si algo más depende del túnel, necesita una señal de preparación que refleje la conexión, no la hora de inicio de la tarea.

Los reintentos deberían ser limitados y distinguir una red ausente de una credencial rechazada. Reiniciar ante cada fallo no puede reparar un certificado caducado y produce un registro lleno de intentos idénticos que oculta el real.

Acepte la tarea en el contexto en el que realmente se ejecutará: sin red al arrancar, con un inicio de sesión normal, con un despertar del sueño y con una parada controlada. Después registre juntos la etiqueta de la tarea, la versión del cliente y la revisión del perfil, para que la siguiente persona herede un servicio atribuible en lugar de un archivo que funcionó una vez.