openvpn3 session-start ignora tu archivo de credenciales

Conéctate con el cliente 2.x y el perfil funciona; entrega el mismo archivo al cliente 3.x y se detiene en una petición de contraseña. Pasa --auth-user-pass creds.txt a openvpn3 session-start y el resultado es el mismo, porque el cliente más nuevo no tiene una etapa que lea el archivo. La negativa es deliberada: las credenciales pertenecen a una sesión, y una sesión la crea un servicio, no el proceso de tu terminal. Elige entre la petición interactiva y el ayudante de carga automática, y sabe qué almacena cada uno.

Por qué el archivo guardado no tiene adónde ir

En el diseño más nuevo, la gestión de la configuración y la gestión de sesiones son servicios separados que hablan por el bus del sistema. Esa separación es lo que permite a un usuario corriente iniciar una sesión sin que un demonio con privilegios lea en su nombre un archivo de contraseñas protegido. Las credenciales basadas en archivos no tienen cabida en ese modelo, porque no hay un arranque del lado del demonio que las leyera. La negativa es consecuencia de la arquitectura, no una función que falte.

Merece la pena nombrar el patrón antiguo para que sea más fácil desaprenderlo: un perfil hace referencia a un archivo de credenciales, y el demonio lo lee cuando arranca el túnel. En el modelo nuevo, las credenciales pertenecen a una sesión y se suministran cuando esa sesión comienza. openvpn3 session-start --config work.ovpn las pide, y --auth-user-pass creds.txt se rechaza porque nada en esa ruta abriría el archivo. Cada receta para 2.x que encuentres supone una etapa que ya no existe.

La configuración y los ajustes locales del sitio también están separados, lo que explica una segunda sorpresa. Un perfil puede parecer completo mientras la conexión que produce carece de configuración de enrutamiento y de resolución. Esas piezas se aplican como ajustes locales del sitio, por separado del archivo importado.

La ruta de la petición y la sesión que deja

Suministrar la contraseña cuando empieza la sesión es el flujo de trabajo previsto. El cliente pregunta una vez, entrega las credenciales al backend de la sesión y continúa:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Por esa ruta no se escribe nada en el disco. La sesión también sigue funcionando después de cerrar el terminal, lo que sorprende a quien espera que el proceso muera con su shell. Ese es precisamente el sentido de trasladar la gestión de sesiones a un servicio. La sesión sobrevive al terminal que la pidió, y hay que detenerla explícitamente.

Para una estación de trabajo con una persona delante, esta es también la opción más segura, porque no hay ningún secreto guardado que proteger u olvidar. Solo es inadecuada donde no hay nadie para escribir.

Automatización sin una persona en el teclado

Donde una máquina tiene que conectarse sin una persona, el proyecto incluye openvpn3-autoload. Lee un directorio de perfiles y un descriptor correspondiente por perfil, y el descriptor suministra las credenciales en texto plano. El ayudante es un binario aparte, normalmente en /usr/sbin/openvpn3-autoload, no una opción de session-start. Configurarlo significa crear el directorio, copiar el perfil con el nombre que el descriptor espera y escribir el descriptor.

Una configuración por usuario tiene este aspecto y se ejecuta como la cuenta que poseerá la sesión. El modo del directorio mantiene fuera a los demás usuarios locales:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

El descriptor nombra las credenciales y pide un inicio automático. Mantén el valor de la contraseña fuera del control de versiones:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Luego invoca el ayudante una vez y confirma que la sesión aparece. El segundo comando es la comprobación, no otro paso de configuración:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Al arrancar, una unidad empaquetada llamada openvpn3-autoload.service usa el directorio de todo el sistema /etc/openvpn3/autoload, no el de cada usuario. Esa ubicación necesita propiedad de root y un modo más estricto, y el descriptor sigue conteniendo la contraseña en texto claro. El compromiso es explícito: la contraseña ahora está en el disco, así que trata ese directorio como un secreto, exclúyelo de las copias de seguridad fuera del host y elige la ruta interactiva siempre que haya una persona.

Fallos del bus que parecen fallos de contraseña

Algunos fallos atribuidos a las credenciales no lo son en absoluto. Un error de permisos que nombra la ruta de activación del servicio significa una de dos cosas: el backend no está en marcha, o quien llama no tiene permiso para activarlo. Ninguna edición del perfil cambiará ninguna de las dos. Comprueba el estado del servicio y la política de bus incluida antes de tocar la configuración.

Los comandos siguientes separan las dos cosas. El primero informa de si el backend está en marcha; el segundo muestra errores de bus recientes:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

La otra lectura errónea frecuente es una sesión que aparece y desaparece de inmediato. Ese patrón suele significar que los ajustes locales del sitio nunca se aplicaron, así que el túnel subió sin los cambios de enrutamiento y de resolución que lo hacen útil. Lee la secuencia en lugar de la última línea: si la sesión se creó, si llegó a un estado conectado y si sobrevivió son tres hechos separados.

Cuando el cliente antiguo sigue en uso

El cliente 2.x todavía acepta un archivo de credenciales, y un llavero puede responder a su petición sin que el secreto llegue nunca al disco. Un envoltorio resuelve la entrada, así que el archivo nombra la búsqueda en lugar de la contraseña. Este arreglo depende de un llavero desbloqueado, algo que un contenedor sin sesión de inicio de sesión o una unidad que arranca antes de que nadie inicie sesión no pueden ofrecer. La herramienta de búsqueda informa entonces de una colección en la que no puede escribir, así que el error parece un fallo de credenciales cuando es un fallo del llavero.

Antes de construir nada de eso, comprueba si un ajuste keepalive del perfil elimina por completo la necesidad de reiniciar. Una sesión que se mantiene no llega nunca a la petición que intentas automatizar.