Cambiar la contraseña de VPN sin dejar fuera a ningún dispositivo

Tres teléfonos, un router y una comprobación de monitorización siguen guardando la contraseña antigua, y uno de ellos se reconecta cada noventa segundos. La contraseña de la cuenta cambió hace diez minutos, así que cada uno de esos clientes envía ahora un valor que el servidor rechaza. Ese es el momento en que el mito se rompe: un cambio de contraseña toca la cuenta, no las copias del valor antiguo que hay en cada dispositivo. Lo que sigue es el trabajo que el cambio no hizo.

El mito: un cambio, en todas partes a la vez

La creencia es que un cambio de contraseña cierra todas las sesiones y obliga a un inicio de sesión limpio. No es así, porque el servidor solo registra qué credencial aceptó por última vez, mientras los clientes conservan lo que guardaron. Un dispositivo con una contraseña guardada la reintenta según su propio calendario y falla en silencio hasta que alguien nota que la cuenta está bloqueada. Cuando aceptas que las copias viven fuera de la cuenta, la rotación deja de parecer una sola acción.

Nada de eso argumenta contra la rotación. Argumenta a favor de tratar las copias guardadas como parte del cambio y no como algo pensado después. Un bloqueo suele venir de reintentos paralelos: cada dispositivo sigue enviando el valor antiguo según su calendario hasta que salta el contador. Entonces la cuenta parece atacada cuando solo se le ofrecen credenciales que nadie sustituyó. Esa distinción importa, porque la solución es una lista de dispositivos y no una política de bloqueo más estricta.

Inventaría las copias antes de rotar

Escribe el inventario antes de abrir el formulario de contraseña. Enumera cada cliente, script, automatización y perfil gestionado que se autentica como esta cuenta: el teléfono que se conecta solo, el router configurado hace dos años, el portátil que solo despierta los lunes y la comprobación de monitorización que lo intenta cada minuto. Para cada uno, anota dónde se guarda la credencial, si se puede alcanzar el dispositivo durante el cambio y qué ruta de recuperación existe si no puede reconectarse. Esa lista es lo que convierte un cambio arriesgado en uno programado, y debe existir antes de que la contraseña antigua deje de funcionar.

Los dispositivos sin conexión son el olvido clásico. Un portátil en un cajón vuelve tres semanas después y presenta el valor obsoleto en el peor momento posible. Anota también su ubicación y su calendario, porque tendrás que perseguirlo en lugar de esperarlo.

En una flota Linux la búsqueda es mecánica y no ingeniosa. Busca perfiles que hagan referencia a un archivo de credenciales, luego busca los archivos de credenciales en sí, porque la segunda lista es la que hay que reescribir. Repite el ejercicio para clientes de escritorio y teléfonos, donde el almacén es un perfil o una entrada de llavero y no una ruta. El objetivo es una lista con la que puedas trabajar, no un escaneo que afirme encontrar cada copia.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Compara las copias con las personas que las poseen. Un dispositivo que nadie reclama es un dispositivo que nadie actualizará, y también es el que más probablemente siga reintentando.

Qué secreto estás rotando en realidad

Una contraseña de cuenta es solo una credencial en un despliegue de VPN. Una frase de paso de clave, una identidad de certificado y un secreto de par opcional tienen cada uno su propia ruta de sustitución y su propio propietario. Cambiar la contraseña de la cuenta no hace nada por un dispositivo que se autentica con un certificado, y reemitir un certificado no hace nada por un cliente que guarda una contraseña. Nombra el secreto antes de nombrar la solución.

Si la rotación viene de la sospecha y no de la política, el proceso de incidente prevalece sobre el plan de comodidad. Revoca lo que exijan las pruebas y acepta el trabajo extra en la lista de dispositivos. Esa decisión corresponde al responsable del incidente, no a quien tenga por casualidad el formulario de restablecimiento de contraseña.

Sustituye el valor guardado donde vive

Cambia la credencial mediante el mecanismo que documenta el servicio, luego actualiza la copia guardada o ejecuta el flujo de inicio de sesión en cada dispositivo que quieras conservar. No edites una configuración generada detrás de un gestor que la reescribe, porque el gestor restaura el valor anterior en su siguiente ejecución y la edición se convierte en un fallo diferido. Actualiza la fuente que lee el gestor o usa el almacén de credenciales propio del cliente. De cualquier forma, el dispositivo debe acabar con el valor nuevo en el lugar donde el cliente lee de verdad.

Un cliente que guarda un archivo de contraseña necesita el archivo reescrito, mientras que un cliente que pregunta necesita un inicio de sesión completado. NetworkManager guarda el secreto dentro del perfil de conexión, así que el cambio pasa por nmcli y no por un editor de texto:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

Un perfil que lee un archivo de credenciales es un tercer caso. Sustituye el contenido de ese archivo, mantén sus permisos cerrados y recarga el cliente en lugar de editar el perfil que apunta a él. El perfil no cambió; solo cambió el secreto que lee.

Reconecta cada dispositivo previsto una vez, a propósito, y observa cuáles fallan. Si un dispositivo sigue fallando, mira la cuenta a la que apunta y el almacén que lee antes de cambiar la contraseña otra vez, porque un segundo cambio multiplica las copias que hay que actualizar. Un dispositivo que falla dos veces suele apuntar a la cuenta equivocada o leer un almacén que aún no has encontrado. Corrígelo y vuelve a conectar.

Las sesiones y los tokens sobreviven a la contraseña

Cambiar la contraseña no demuestra que las sesiones existentes o los certificados separados se hayan revocado. Algunos servicios mantienen viva una sesión hasta que expira o se termina explícitamente, y los tokens emitidos llevan su propia vida útil. Comprueba qué hace realmente el servicio en lugar de suponer que el cambio fue global. Si el cambio vino de la sospecha, termina las sesiones explícitamente y confirma el resultado.

La guía del ciclo de vida de las credenciales de NIST SP 800-63B mantiene autenticadores y sesiones en categorías separadas, y por eso un cambio de contraseña y un cierre de sesión global son operaciones distintas. Trátalos como dos tareas con dos criterios de finalización. La primera termina cuando funciona el valor nuevo, y la segunda cuando las sesiones antiguas han desaparecido.

Registra la finalización sin escribir la contraseña nueva en el registro. Un registro de rotación que contenga la credencial es un incidente nuevo esperando en un disco compartido. Anota la fecha, los dispositivos actualizados y los dispositivos aún pendientes.