Por qué un servicio VPN iniciado en el arranque no puede leer tu llavero
Una VPN en el arranque no tiene ningún agente de secretos desbloqueado del que tomar prestado. Lee las marcas de secreto de la conexión antes de restablecer una contraseña que el servidor nunca rechazó.
Una conexión que funciona tras iniciar sesión y falla antes suele significar que el intento de arranque no pudo obtener un secreto, no que el servidor rechazara uno. La credencial existe; el contexto que la pide, no. Esa única distinción ahorra un restablecimiento de contraseña innecesario.
Sigue la petición: algo inicia la conexión antes de que exista una sesión de escritorio, y el almacén de secretos que normalmente responde aún no se ha desbloqueado. Los dos contextos no coinciden sobre quién posee el secreto, y el perfil registra cuál de ellos se espera que lo proporcione.
Qué pide realmente la ruta de arranque
Al arrancar, NetworkManager se inicia como servicio del sistema sin sesión de usuario, sin D-Bus de sesión y sin llavero desbloqueado. Un perfil de conexión todavía puede levantarse, pero solo con secretos que el servicio pueda alcanzar por sí mismo. Todo lo que posee un agente de secretos se queda esperando hasta que una persona inicia sesión y el agente aparece. El servicio hace exactamente lo que dice su configuración; el perfil es lo que tiene que cambiar.
El fallo está escrito en la conexión, no escondido en un llavero.
Leer las marcas de secreto de una conexión
Pregunta a la conexión qué espera, no qué recuerda el escritorio. La columna de marcas responde directamente a la pregunta y sobrevive a los reinicios en el archivo de perfil del disco.
Empieza por la lista de perfiles y confirma qué conexión está configurada para levantarse sola. Después vuelca una conexión y lee las marcas de contraseña:
nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show nmcli connection show "Work VPN" | grep -i -E "password|secret|key" journalctl -b -u NetworkManager --grep "secret"
El primer comando confirma qué perfiles existen y si alguno está configurado para conectarse automáticamente, que es como se inicia un intento sin supervisión. El segundo expone los valores de las marcas, y el tercero muestra al servicio quejándose de que ningún agente respondió para un secreto dado. Una línea de registro que nombra un secreto como propiedad de un agente es todo el diagnóstico en una frase.
| Flag value | Where the secret lives | Behaviour before login |
|---|---|---|
| 0 | Stored in the connection profile | Available to the system service |
| 1 | Owned by a secret agent | Blocks until the agent is unlocked |
| 2 | Never stored | Prompts on every activation |
| 4 | Not required | Never requested at all |
Por qué mover la conexión al ámbito del sistema cambia la respuesta
Una conexión propiedad de un usuario se activa bajo el agente de ese usuario, por eso funciona perfectamente en cuanto el escritorio está arriba. Moverla al ámbito del sistema quita el agente del camino, así que el mismo perfil se comporta distinto sin cambiar ni una línea de configuración de la VPN.
Ese movimiento es un diseño legítimo y conlleva un requisito: el secreto tiene que ser accesible para el servicio del sistema. Guardarlo en el perfil, proporcionarlo mediante una credencial de ámbito de sistema o aceptar una petición interactiva en el momento adecuado son todas respuestas válidas. Dejar la marca 1 y esperar, no.
Una clave privada con su propia frase de contraseña añade una segunda capa. Ni siquiera una contraseña de cuenta guardada desbloqueará una clave que pide una frase de contraseña, así que verifica qué secreto pide realmente la etapa que falla antes de cambiar nada.
Qué no hacer y qué hacer en su lugar
Hacer que todos los archivos de credenciales sean legibles por cualquiera, o desactivar la autenticación para que no haga falta ninguna petición, cambia una molestia de arranque por una exposición permanente. Ambos también ocultan la dependencia en lugar de resolverla, y la siguiente actualización de la imagen reintroduce el mismo fallo.
Usa el mecanismo que tu distribución documenta para la activación sin supervisión en esa etapa y luego confirma que las marcas del perfil coinciden con él. Comprueba el resultado desde un arranque limpio, no desde un intérprete que ya tiene un agente. Anota el propietario de la conexión, la fuente del secreto y la etapa que debe funcionar, para que un cambio posterior de inicio automático no pueda reintroducir en silencio una dependencia de que alguien desbloquee primero un escritorio. La documentación es la diferencia entre un servicio arreglado y uno que vuelve a romperse el próximo trimestre.
Prueba desde un arranque limpio controlado, no desde un reintento manual tras iniciar sesión. El reintento tiene éxito por el motivo por el que falló el intento de arranque, y eso es justo la evidencia que una prueba rápida destruye.