¿OpenVPN no arranca y no muestra ningún error? Mire el journal

El comando regresa, el servicio aparece como fallido y nada que se parezca a una explicación llega al terminal. Ese silencio es el síntoma que la gente describe como «OpenVPN no arranca», y casi nunca significa que el programa murió sin decir nada. Significa que el mensaje fue a un canal que no estaba leyendo, o que lo que inició no era lo que había configurado. Ambos casos se diagnostican en menos de un minuto en cuanto deja de tratar el perfil como el sospechoso.

Cuatro lugares absorben la salida: el journal de la unidad, el complemento que posee la conexión, el otro extremo del túnel y un binario distinto del que cree que se ejecuta. Cada uno tiene su propia comprobación.

El silencio significa que no estaba mirando el canal correcto

Una invocación en primer plano imprime en su terminal. Una unidad imprime en el journal, y una unidad fallida puede salir antes de escribir nada si el fallo está en cómo se inició y no en lo que se le dijo. La distinción importa: ninguna entrada en el journal significa que el proceso nunca se ejecutó de verdad, mientras que una entrada seguida de una salida significa que se ejecutó y rechazó algo.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Añada systemctl show -p Result -p ExecMainStatus openvpn-client@office para separar una salida limpia de una señal. Un estado 1 con un Result=exit-code es una decisión del programa; Result=signal o un tiempo de espera apuntan más bien al entorno, y ninguna cantidad de edición del perfil lo cambiará. Anote ambos valores antes de reiniciar nada, porque un reinicio borra el estado transitorio que los produjo.

El nombre de la instancia forma parte de la ruta

La unidad de plantilla empaquetada no acepta una ruta de archivo. Acepta un nombre de instancia, y ese nombre se añade a un directorio para encontrar el perfil: office se resuelve en /etc/openvpn/client/office.conf en el empaquetado de Debian y Ubuntu. Un archivo llamado office-v2.conf iniciado como @office nunca se lee, y la unidad sale en silencio porque desde su punto de vista no había nada que hacer. El directorio de búsqueda difiere entre el modo cliente y el modo servidor, así que el mismo error apunta a un sitio completamente distinto al cambiar de plantilla.

Esa discrepancia es la causa más común del fallo silencioso, y es invisible en el perfil porque el perfil está bien. Enumere lo que existe realmente y compare los dos nombres carácter por carácter, incluida cualquier extensión que espere el empaquetado.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Si la unidad está habilitada pero no aparece ninguna instancia, la propia habilitación puede hacer referencia a un nombre que luego se renombró. Volver a habilitar la instancia correcta suele bastar, y merece la pena borrar el archivo de unidad antiguo que queda para que no confunda a la siguiente persona. Un archivo de unidad olvidado es una tontería que luego le cuesta una hora a alguien.

Cuando el complemento posee el túnel, el terminal no ve nada

Una conexión iniciada desde el applet de escritorio pertenece a NetworkManager, y su salida de OpenVPN va al journal de ese servicio en lugar de a cualquier shell que tenga abierto. Ejecutar el cliente a mano y no ver nada es lo esperado en esa disposición, porque el proceso ejecutado a mano no es el que lleva la conexión.

Busque en el journal el servicio que lo posee, y luego reproduzca el análisis con una verbosidad que pueda leer. Los dos comandos siguientes miran a propietarios distintos del mismo fallo.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

La ejecución independiente sirve para leer mensajes, no para sustituir la conexión gestionada, y las dos difieren después: la integración de DNS, las rutas y la duración pertenecen al complemento. Corregir un error de análisis en la ejecución independiente no corrige automáticamente la resolución de nombres cuando el applet toma el control, así que mantenga las dos observaciones separadas.

Dos binarios, un PATH

Una compilación manual instalada bajo /usr/local gana en una invocación de shell, porque /usr/local/sbin precede a /usr/sbin en el PATH predeterminado de Ubuntu. Una unidad no usa su PATH; ejecuta la ruta absoluta escrita en ExecStart. Así que la versión que funciona en su terminal y la versión que falla como servicio pueden ser programas genuinamente distintos.

Compare los dos antes de reconstruir nada. El tercer comando es el que decide el argumento.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Otra diferencia de entorno se esconde en el mismo sitio. Una unidad empaquetada depende de un directorio de ejecución bajo /run que systemd crea para ella; una unidad de reemplazo escrita a mano que omita ese ajuste puede fallar antes de abrir un solo archivo, y el fallo parece un rechazo genérico sin ningún mensaje de OpenVPN.

Fallos que el cliente no puede informar

Algunos resultados se deciden en el extremo remoto. Una puerta de enlace que responde con un estado HTTP y cierra la conexión le ha dicho cuál es su propio estado, y el siguiente paso útil es su registro o la cuenta detrás de la credencial en lugar de sus archivos locales. Nada local está roto en ese escenario, y editar el perfil para compensarlo hace más difícil el siguiente diagnóstico. Lea ese registro antes de tocar la configuración del cliente.

Otro caso silencioso es un cliente que funciona correctamente. Un túnel en modo cliente nunca escucha en un puerto, así que una comprobación que espere un oyente abierto no informará de nada y parecerá un fallo. Confirme qué modo inició antes de sacar conclusiones de una lista de puertos vacía.

Trabaje las capas en orden: ¿existe la unidad y es correcto el nombre de la instancia, llegó algo al journal o al archivo --log, qué binario y qué perfil se ejecutaron realmente y si el fallo es local o remoto? Cada respuesta elimina una capa. Empezar por el perfil significa reescribir un archivo que quizá nunca se abrió.