status=200/CHDIR: systemd nunca llegó a iniciar OpenVPN

El servicio falla, los registros mencionan un spawn y un directorio, y el primer instinto es revisar la configuración de la VPN. En ese archivo todavía no se ha leído nada. systemd falló mientras preparaba el proceso, antes de que se ejecutara el ejecutable, así que no se ha consultado ningún analizador, ningún certificado ni ningún host remoto. Leer el código de estado como una afirmación sobre systemd en lugar de sobre OpenVPN es lo que convierte esto en una investigación breve.

Lee el código de estado antes que la aplicación

El código numérico después del nombre del servicio nombra la etapa que falló. Un fallo de directorio se informa como estado CHDIR, mientras que un ejecutable que no se pudo ejecutar es un código completamente distinto. Los dos se parecen en una línea de resumen y no tienen nada en común en sus causas.

Esa distinción importa porque las correcciones están en archivos distintos. Un fallo CHDIR tiene que ver con una ruta y con cómo la ve el servicio. Un fallo de exec tiene que ver con el binario, su intérprete o un montaje no relacionado. Cambiar el remoto de la VPN, la lista de cifrados o la ruta del certificado no puede resolver ninguno de los dos.

Confirma que el fallo es al arrancar y no después de una ejecución correcta. Si el servicio funcionaba ayer y ahora falla en la misma etapa, algo ha cambiado en el directorio, sus permisos o la propia unidad, y ese cambio es la evidencia que hay que buscar.

Pregunta a la unidad dónde quiere estar

Lee la unidad efectiva en lugar del archivo que crees que está instalado, porque los drop-ins pueden sobrescribir el directorio de trabajo sin que hayas editado nunca la unidad principal. La salida de show responde directamente a la pregunta:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Para la plantilla del servidor upstream, el directorio de trabajo es el directorio de configuración del servidor y el nombre de la instancia selecciona el perfil que hay dentro. Una instancia llamada branch, por tanto, espera su propio archivo en ese mismo directorio, y un perfil colocado en otro sitio no cumple en absoluto el requisito del directorio de trabajo.

Compara lo que pide la unidad con lo que existe. Una ruta que antes existía, un enlace simbólico que ahora apunta a otro sitio o un nombre de instancia que ya no coincide con un directorio son cambios corrientes que producen exactamente este fallo.

Comprueba la ruta tal como la ve el servicio

Tu shell y el servicio no comparten la misma vista del sistema de archivos. Un directorio raíz o una imagen raíz configurados cambian lo que significa una ruta absoluta dentro de la unidad, y una ruta que está obviamente presente en el host puede faltar en ese espacio de nombres. Lee los ajustes de la unidad antes de fiarte de una prueba manual.

Los permisos agravan el problema. El servicio se ejecuta como un usuario concreto, y ese usuario debe poder atravesar cada directorio padre para llegar al objetivo, no solo leer el objetivo en sí. Un directorio legible por root y no atravesable por el usuario del servicio produce un fallo que parece una ruta inexistente.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

Los ajustes de endurecimiento también forman parte de este cuadro. Una unidad que oculta los directorios personales o hace de solo lectura una parte del sistema de archivos hace exactamente lo que se le configuró, y el directorio de trabajo debe vivir en un lugar que el sandbox todavía exponga.

Corrige el propietario y luego espera otro error

Corrige la disposición o la unidad a través de quien posea esa configuración. Mover un perfil al directorio esperado es una corrección legítima cuando la disposición es incorrecta, pero no explica un directorio al que no se puede entrar, así que no lo trates como la respuesta general.

Resiste el atajo de ampliar los permisos en el árbol de configuración o de eliminar el sandbox. Ambos hacen desaparecer el síntoma mientras eliminan las protecciones que se pusieron ahí deliberadamente, y el siguiente fallo será más difícil de interpretar.

Reinicia la instancia y lee el siguiente evento en lugar de dar por hecho el éxito. El siguiente error probable es que OpenVPN no pueda abrir su archivo de configuración, lo cual es un avance: se ha entrado en el directorio de trabajo y el analizador ya se ejecuta. Sigue el mapeo real de archivos de la unidad desde ahí en lugar de volver a la resolución de problemas de red.

La referencia de ejecución de systemd define cómo se interpreta el directorio de trabajo junto con los directorios raíz y el aislamiento. El patrón que hay que recordar es simple: cada código de estado nombra una etapa distinta, y solo los errores propios de la aplicación describen la aplicación.