Tu VPN solo funciona tras iniciar sesión por el llavero

El comando funciona cuando has iniciado sesión, así que lo pones en un script de arranque y te vas a casa. A la mañana siguiente la máquina está en línea y el túnel no. El mito es que una invocación que funciona es un servicio que funciona. En la práctica, la diferencia suele ser una de dos cosas: el perfil pertenece a tu sesión de usuario en lugar del sistema, o el secreto lo desbloquea algo que solo existe después de que inicias sesión. Ambos funcionan a la perfección en una prueba manual y fallan justo en el momento en que nadie mira.

Por qué iniciar sesión lo hace funcionar

Un inicio de sesión gráfico arranca un bus de sesión y un agente del servicio de secretos, y ahí es donde muchos clientes orientados al escritorio guardan la contraseña del perfil o la frase de paso de la clave privada. Una activación que se ejecuta como tu usuario tras iniciar sesión puede pedirle el secreto a ese agente y tener éxito. La misma activación ejecutada por una unidad de arranque no tiene sesión, ni bus, ni agente, así que la búsqueda falla o se bloquea en un aviso que nadie ve.

Ejecuta el mismo perfil antes y después de iniciar sesión y obtendrás dos resultados distintos de una sola configuración. Esa es la firma de una dependencia de credenciales, no de un túnel roto, y explica por qué una prueba manual en una terminal demuestra menos de lo que parece. El túnel está bien; falta lo que desbloquea su secreto.

Decide qué propietario inicia el túnel

Hay dos patrones admitidos, y mezclarlos es la otra forma en que esto falla. NetworkManager puede activar una conexión de ámbito de sistema, lo cual es apropiado cuando la máquina ya centraliza ahí su red. Como alternativa, una unidad systemd dedicada ejecuta la VPN directamente y posee la interfaz.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

No ejecutes ambos propietarios contra una misma configuración. Si NetworkManager gestiona la interfaz y una unidad también la levanta, se pelearán por las rutas y el DNS, y el estado resultante depende de quién terminó último.

Pon el secreto donde el servicio pueda leerlo

Un servicio en segundo plano no puede responder a un aviso. Las frases de contraseña de certificados, las contraseñas de cuenta y los archivos de autenticación referenciados necesitan una disposición de almacenamiento que la unidad pueda alcanzar sin un humano, propiedad de la cuenta que ejecuta el servicio y ilegible para todos los demás.

El atajo tentador es hacer que el archivo sea legible por todos hasta que el error de permisos desaparezca. Eso cambia un fallo de arranque por una exposición de credenciales de larga duración, y es el tipo de cambio que nadie revisa. Usa el mecanismo en el que ya confía el despliegue: un archivo de credenciales restringido, una clave no cifrada protegida por los permisos del archivo, o una conexión de ámbito de sistema con su propio almacén de secretos.

Prueba el evento que ocurre de verdad

Iniciar el servicio a mano tras el inicio de sesión no prueba casi nada. Reinicia, o desactiva el inicio de sesión gráfico durante un ciclo, y observa cómo la unidad se levanta sola. Esa es la única prueba que ejercita a la vez la disponibilidad de credenciales, la preparación de la red y el orden de las unidades. También es la prueba que reproduce el fallo que notificó el usuario, algo que un inicio manual nunca hace.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

El orden importa tanto como las credenciales. Una unidad que arranca antes de que esté configurado el enlace ascendente subyacente se rendirá, y algunas distribuciones difieren en si esperan la conectividad. Si la unidad informa de un fallo al arrancar pero tiene éxito cuando la inicias a mano treinta segundos después, has encontrado un problema de orden y no un problema de secreto.

Verifica rutas y DNS, no solo la interfaz

Una interfaz que existe no es un túnel que funciona. Tras un arranque sin supervisión, comprueba las rutas, el estado del resolutor y un destino por dirección antes de comprobar un nombre. Después comprueba la aplicación para la que existe el túnel.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Si la dirección funciona y el nombre no, el problema restante es la política de DNS y no el túnel. Anota qué propietario inicia el servicio y dónde vive el secreto, porque la próxima persona que reinicie esta máquina necesitará ambos datos.