OpenVPN 3 Linux: lee un error de D-Bus antes de revertir

Los fallos de OpenVPN 3 Linux llegan como un error de método D-Bus con un nombre desconocido adjunto, y la tentación es degradar un paquete y esperar. El cliente no es un solo programa: un frontal de línea de comandos habla por el bus con servicios que poseen los perfiles, las sesiones, el motor VPN y los cambios de red privilegiados. Decidir cuál de esos cinco posee la llamada que falla es la mayor parte del diagnóstico, y cuesta un comando en lugar de una reversión. Lo que sigue es esa decisión, en el orden en que los fallos suelen aparecer.

Cinco dueños detrás de un comando

Cinco procesos importan, y cada uno tiene su propio nombre de bus: el frontal que acepta tu comando, el gestor de configuración que guarda los perfiles y su política de acceso, el gestor de sesiones que posee la vida de las sesiones, el backend que ejecuta la conexión mediante OpenVPN 3 Core Engine, y el servicio de configuración de red que instala la interfaz, las rutas y los ajustes de DNS. Un error que nombra un objeto de configuración no es por tanto un error del backend, y un backend que no arranca no es un fallo de autenticación. Clasificar el mensaje en una de esas filas debe ocurrir antes de cambiar nada, porque cada paso posterior depende de qué fila es verdadera. Adivinar la fila es la forma en que una corrección breve se convierte en una tarde de trabajo con paquetes.

Pregunta al bus del sistema qué servicios están presentes antes de preguntar cualquier otra cosa, y confirma después que las piezas instaladas coinciden en una versión. OpenVPN 3 Linux registra esos servicios como unidades del sistema, así que el bus que hay que consultar es el del sistema, la consulta de versión necesita autoridad administrativa, y un listado hecho con --user lee tu sesión de inicio de sesión, donde las unidades nunca aparecen. Los servicios se activan a demanda y algunos se detienen cuando están inactivos, así que un servicio que falta antes de tu primera solicitud simplemente no ha recibido ninguna petición todavía. Los tres comandos de abajo responden sobre presencia, versión y estado de las unidades sin abrir una sesión VPN.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Lo que cada lista demuestra realmente

Las vistas propias del cliente son la evidencia más barata disponible, y cada una de ellas demuestra menos de lo que parece. Un perfil en la lista de configuración muestra que un perfil está importado y nada sobre si alguien puede conectarse con él. Una sesión en la lista de sesiones muestra que existe un objeto de sesión y nada sobre si la autenticación remota terminó.

openvpn3 configs-list
openvpn3 sessions-list

Las rutas de objeto de esas salidas identifican objetos gestionados en el bus y no archivos, así que no se pueden editar, y una ruta anotada antes queda obsoleta en el momento en que esa sesión se desconecta. Reutilizar una de tus notas produce errores "no such object" que no tienen nada que ver con la VPN. La tabla de etapas de abajo separa lo que cada paso de una conexión establece de lo que deja abierto, y esa es justo la distinción de la que depende una decisión de reversión. Lee la fila que coincide con tu evidencia y vuelve a leer el texto del error.

La llamada de conexión regresa antes de que exista el túnel

La llamada de conexión te entrega una sesión que observar y regresa, por eso una llamada aparentemente correcta seguida de silencio es un estado intermedio normal y no una contradicción. El frontal todavía tiene que seguir los cambios de estado y responder a cualquier petición de interacción. Un perfil que necesita una credencial y no recibe respuesta espera en un estado que se parece exactamente a un backend colgado. Ese estado de espera merece reconocerse, porque manda a la gente al componente equivocado.

Mientras hay un intento en marcha, vigila la lista de sesiones y el registro propio del frontal para ese perfil. Una sesión que nunca sale de su estado inicial nombra el componente que se detuvo, y el registro suele nombrarlo en las primeras líneas. Ten a mano el nombre del perfil, ya que el comando de registro toma un perfil y no una ruta de sesión, lo que es una razón más para releer la lista en lugar de reutilizar una ruta.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Leer el registro de un componente sin abrir una sesión

Cuando el frontal no informa nada útil, ve a el componente que registró el fallo en lugar de iniciar otra conexión. Con un registrador systemd-journald configurado, la vista de journal acotada del administrador lee los eventos de un componente sin tocar la política del bus ni abrir una sesión, lo que importa porque un diagnóstico que cambia el sistema que mide demuestra muy poco. Filtra por unidad en lugar de por etiqueta de syslog: las unidades de servicio individuales no garantizan un identificador compartido, así que una consulta por etiqueta puede devolver una página vacía mientras la propia unidad registró el fallo.

Anota cuatro campos antes de pedir ayuda a alguien: el nombre completo del error, el servicio y el objeto implicados, la marca de tiempo y las versiones de paquete instaladas. Eso es lo que necesita quien mantiene el paquete, y nada de ello exige pegar un perfil o una credencial en un ticket. Ampliar la política de acceso al bus para silenciar el error no es un diagnóstico, borra la frontera que estaba nombrando el componente por ti. El contenido privado de los perfiles queda fuera de los informes compartidos por la misma razón que las credenciales.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Corregir la frontera que rechazó

Cada fila del mapa tiene su propia corrección, y las filas no se sustituyen entre sí. Una operación denegada sobre un perfil es una cuestión de política y propiedad, mientras que un backend que no se activa es una cuestión de servicios y empaquetado. Un servidor que rechaza la autenticación no es ninguna de las dos, así que los cambios repetidos de contraseña no pueden reparar un problema de activación local. Elegir la corrección equivocada es como un problema de política se convierte en una reinstalación.

Después de un cambio de paquetes, verifica una instalación coherente y soportada en lugar de copiar un binario antiguo en su sitio. Una reversión controlada es una respuesta legítima a una regresión confirmada, siempre que los paquetes sigan siendo compatibles y exista una ruta de vuelta al mantenimiento soportado. Establece esa ruta antes de que el servicio deje de arrancar, no después.

Otra plataforma puede compartir la misma biblioteca VPN central sin compartir los servicios de bus de Linux, así que un fallo de aspecto similar en Windows no dice nada sobre este. La visión general de D-Bus documenta las rutas de objeto expuestas para configuraciones y sesiones, y esa es la parte de la arquitectura de la que depende este diagnóstico. Léela una vez, y el próximo error llegará con un componente ya adosado.