OpenVPN se inició pero no imprimió nada: revise primero log-append

Inicia OpenVPN desde un shell con un archivo de configuración, y el terminal se queda sin ninguna salida. Ni banner, ni error, ni indicador. El instinto dice que el lanzamiento falló, así que inicia otra copia, luego otra, y la máquina acaba con varias instancias a medio configurar. Antes de nada, revise el perfil en busca de una directiva que ya haya redirigido el registro a otro lugar. El silencio es una propiedad de la consola, no del proceso.

El silencio tiene dos explicaciones muy distintas

La primera es que el proceso funciona bien y escribe en un archivo que usted no está observando. La segunda es que salió de inmediato con un error registrado en ese mismo archivo.

Ambas dejan un terminal vacío, y una sola pregunta las separa: hay un proceso ahora y qué hay en el archivo al que se le dijo que escribiera. Responda eso antes de tocar de nuevo la configuración. Relanzar para obtener salida es como dos instancias acaban peleando por un dispositivo de túnel y el mismo puerto, lo que produce errores que no tienen nada que ver con el problema original.

Encuentre la directiva y luego encuentre el proceso.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Encuentre el destino que usa el proceso en ejecución

Lea el perfil con el que realmente se inició el proceso, no el que editó. Una instancia gestionada por un servicio suele cargar una ruta distinta y ejecutarse con un directorio de trabajo distinto, así que un nombre de archivo relativo se resuelve en un lugar que no esperaba.

Una directiva cd explícita agudiza esa distinción, porque la ruta relativa se mueve con el cambio de directorio. Si heredó esta configuración, el archivo puede estar en un lugar donde ahora nadie lo buscaría.

Compare la hora de modificación del archivo con el momento en que lo lanzó. Un registro de la semana pasada es evidencia sobre la semana pasada. Luego lea las últimas líneas del archivo que cambió y trate lo que haya allí como el mensaje de inicio que le faltaba.

log frente a log-append: evidencia y borrado

log-append añade a lo que ya hay en el archivo. log abre el archivo para escribir y lo trunca, así que cambiar entre ambos puede borrar la ejecución que estaba a punto de leer.

Si alguien cambió la directiva mientras depuraba, la evidencia anterior ya se ha ido y el tamaño del archivo parecerá sospechosamente pequeño. Vale la pena saberlo antes de comparar dos ejecuciones y concluir que algo cambió. Borre un registro a propósito o consérvelo, pero sepa cuál de las dos cosas hizo. La evidencia que eliminó deliberadamente es más fácil de razonar que la que perdió por accidente.

Ninguna de las dos opciones crea directorios principales que falten, y ninguna concede acceso mediante permisos del sistema de archivos o un sandbox de servicio. Una ruta que en la configuración parece correcta puede seguir sin ser escribible por la cuenta con la que se ejecuta el demonio, y en ese caso el demonio puede fallar antes de poder informar de nada. Compruebe si el directorio existe y quién es su propietario antes de suponer que el problema es el nombre del archivo.

Cuando un envoltorio de servicio captura la salida

Bajo systemd, la salida estándar y el error van al journal salvo que una directiva de archivo explícita tenga prioridad, y un envoltorio del proveedor puede capturarlos en un lugar completamente distinto.

Por eso el mismo perfil se comporta de forma distinta desde un shell y desde una unidad. El entorno de la unidad, su directorio de trabajo y sus flujos estándar difieren de su shell interactivo. Una ruta relativa puede resolverse en un contexto y no llegar a ningún sitio en el otro. Lea la definición de la unidad cuando los dos discrepen, no el perfil.

Compare las dos formas de lanzarlo en lugar de concluir que una de ellas está rota. Lea la línea de comandos de la unidad y su entorno, y luego lea el journal para la misma ventana de tiempo. Si el envoltorio redirige la salida a su propio archivo, ese archivo es ahora su registro, y las directivas de OpenVPN son irrelevantes para dónde fueron los mensajes.

Suba la verbosidad solo cuando ya pueda leerla

Aumentar la verbosidad antes de encontrar el destino solo produce más texto en un lugar que no está mirando.

Una vez que sepa dónde va a parar la salida, un nivel moderado muestra que el perfil se está analizando y que se intenta la conexión. Dos o tres bastan para un problema de inicio. Los niveles más altos se ganan su sitio cuando el fallo es un detalle de la negociación, y además hacen crecer el archivo deprisa.

Luego lea el error real. Un terminal silencioso no demuestra nada sobre si el túnel subió, y el fallo registrado en el archivo es el que merece la pena corregir.