OpenVPN no arranca: lea la primera línea, no la configuración

Una VPN que muere en el primer segundo es un animal distinto de una que se conecta y luego falla, y el error habitual es tratarlas como la misma cosa. Aquí no hay handshake, ni intercambio de certificados, ni ruta que examinar. Una línea del registro decide cuál de varias reparaciones no relacionadas se aplica, y saltársela cuesta una tarde editando una configuración que nunca se leyó. Lea esa línea primero.

Tres órdenes de solo lectura le llevan allí: primero journalctl -u openvpn@server -b --no-pager, después systemctl status openvpn@server, y ss -lunp para los oyentes UDP y sus propietarios.

La primera línea elige la rama

Un conflicto de puertos y un binario ausente matan el arranque en menos de un segundo, y dejan primeras líneas distintas. Un mensaje de que la dirección ya está en uso nombra el puerto; un ejecutable ausente nombra una ruta que ya no existe; una condición fallida o un archivo de configuración ausente nombra el archivo. Esas tres llevan a reparaciones distintas, y ninguna mejora reinstalando el cliente. Copie el primer fallo en sus notas antes de ejecutar cualquier otra cosa.

Vigile el bucle de reintentos que oculta la línea original. Una unidad con una política de reinicio puede enterrar el primer fallo bajo una docena de idénticos, así que journalctl -b filtrado por la unidad y leído desde arriba supera la cola.

Quién más tiene el puerto 1194

El culpable normalmente no es un segundo servidor que alguien haya configurado a propósito. Espere un cliente iniciado a mano todavía vivo en otra terminal, un segundo perfil que eligió el mismo puerto, o un paquete de proveedor cuyo propio túnel tiene el 1194. El propietario del socket aparece en ss -lunp; pase ese PID a systemctl status para saber si una unidad es responsable. Bájelo por su propio camino de control en lugar de con una señal.

Una señal a un proceso gestionado por una unidad suele provocar un reinicio, y el mismo fallo reaparece momentos después como un problema nuevo. Use systemctl stop para una unidad, la orden de servicio del propio paquete para una instalación de proveedor, y una señal solo para algo que usted inició a mano en esa shell.

Unidades que quedan tras una purga

Una purga borra binarios; los archivos de unidad escritos a mano, normalmente en /etc/systemd/system, sobreviven. Systemd reintenta entonces una unidad que apunta a una ruta que ya no existe, y el mensaje se refiere a ese archivo ausente y no a la eliminación de ayer. systemctl status muestra la ruta del fragmento de la unidad cerca de arriba, así que compruébela con dpkg -S antes de borrar nada. Una vez que el huérfano desaparece, systemctl daemon-reload y systemctl reset-failed limpian el estado; de lo contrario, cada comprobación de estado posterior lo hereda.

Cuando which openvpn responde con algo bajo /usr/local, el binario en juego vino de un instalador de proveedor y no de apt. Ese instalador suele traer su propio oyente, su propia entrada de arranque y su propio directorio de configuración, así que eliminar la orden visible deja el socket ocupado.

Desinstálelo con lo que documente el proveedor, confirme que el puerto está libre con ss -lunp, y añada el cliente de la distribución solo si lo necesita.

Ordene el estado antes de reintentar

Limpie el estado de fallo antes de sacar conclusiones: systemctl reset-failed elimina los contadores, y systemctl status informa entonces del estado actual de la unidad y no de su historial. Iníciela una vez y lea el registro de esa instancia en lugar del estado agregado de la máquina. Una unidad que informa de actividad mientras el túnel no transporta nada es un problema aparte, y mucho más común. Los dos se fusionan en los informes de errores porque ambos acaban con el usuario diciendo que la VPN no funciona.

Anote la rama que tomó: conflicto de puertos, binario ausente, configuración ausente. La próxima vez será más rápido reconocerla.