Un dispositivo sigue sin conectarse tras restablecer la contraseña del VPN
La contraseña nueva funciona en todas partes menos en un cliente. Encuentre el almacén que aún conserva el valor antiguo, limite los intentos y verifique con un solo intento.
Restableció la contraseña, la probó en el portal, y un portátil sigue sin poder conectarse. El instinto es restablecerla otra vez, y así es como una cuenta se bloquea y un secreto antiguo se convierte en un incidente. Un cliente VPN rara vez pide la contraseña cada vez; la pide una vez y guarda la respuesta en algún lugar que usted no eligió. Encontrar ese lugar es todo el trabajo, y es más rápido que otro restablecimiento.
Confirme qué envía realmente cada cliente
Compruebe la cuenta, el dominio y la puerta de enlace en el cliente que falla antes de suponer que la contraseña es el problema. El inicio de sesión del portal web puede usar un sistema de identidad distinto del propio VPN, así que un inicio de sesión correcto en el portal no dice nada sobre la autenticación del protocolo. Algunos despliegues aceptan un correo electrónico en el portal y un nombre de usuario distinto en el túnel. Confirme qué identidad está configurado el cliente para presentar antes de restablecer nada.
Lea el texto del error y clasifíquelo. Un fallo de certificado, un desafío caducado o un cifrado no compatible no es una contraseña antigua, y tratarlo como tal produce un bucle de restablecimientos sin efecto. Si el servicio tiene una política de bloqueo, deténgase tras dos o tres intentos fallidos y confirme el estado de la cuenta antes de continuar.
Enumere los almacenes en lugar de adivinar
Cuatro almacenes guardan un secreto de VPN, y la tabla de abajo muestra para cada uno dónde sobrevive el valor y qué significa realmente borrarlo. Un perfil nativo del sistema operativo guarda el secreto en el almacén de credenciales de la plataforma, por eso la entrada puede sobrevivir a la aplicación que la escribió. Un archivo de configuración del cliente guarda el valor donde lo lee ese cliente, ya sea en línea o en un archivo de autenticación referenciado, así que editar otro archivo no cambia nada. Una cookie del portal y una credencial entregada por política viven en un lugar que el dispositivo no posee de verdad, lo que decide quién puede cambiarlas.
| Store | Where it lives | How to clear it |
|---|---|---|
| Native OS profile | Windows Credentials, NetworkManager secrets | forget or edit the connection |
| Client configuration file | a referenced auth file or inline value | edit the file the client actually reads |
| Browser session | cookie for the portal SSO | sign out of the portal, not just close the tab |
| Managed policy | delivered by the management service | change it in the manager, not on the device |
Compruébelos en un orden fijo: primero el almacén de credenciales del sistema operativo, porque es el que el cliente consulta por defecto, después la caja fuerte o el archivo de configuración del propio cliente, luego la sesión del navegador y por último la política que puede sobrescribir los tres. El orden importa porque un almacén posterior puede restaurar silenciosamente uno anterior, y habrá arreglado la capa equivocada mientras el fallo persiste. Anote qué almacén cambió, porque esa nota es lo que convierte el siguiente restablecimiento en una tarea de dos minutos en lugar de una tarde.
Mire en el almacén que el cliente usa realmente
Lea antes de borrar, para saber qué entrada pertenecía al VPN. Los comandos de abajo listan e inspeccionan en lugar de eliminar, lo que mantiene el diagnóstico reversible.
# Windows credential store
cmdkey /list | findstr /i vpn# Windows native profile
Get-VpnConnection -Name "Work" | Select-Object -ExpandProperty Guid# macOS Keychain
security find-generic-password -s "Company VPN" -g# Linux NetworkManager
nmcli -s connection show "Work" | grep -i passwordEn Linux, -s muestra secretos que NetworkManager oculta de otro modo. En macOS, el comando de Keychain imprime el elemento guardado, así que trate el desplazamiento del terminal como sensible. Si el cliente que falla es una aplicación de terceros con su propia caja fuerte, el almacén del sistema parecerá correcto mientras la aplicación guarda su propia copia, y esa caja fuerte es donde corresponde el cambio.
Ocupe los dispositivos que están sin conexión
Portátiles que se despiertan y se reconectan solos seguirán presentando el secreto antiguo mientras exista su copia. Planifique la actualización para que esos dispositivos se corrijan antes de que reintenten en bloque, y considere desactivar la conexión automática en el perfil afectado hasta que cada uno haya pasado por el flujo compatible.
Para una flota gestionada, cambie el valor donde se define la política. Editar una copia local en un dispositivo cuya credencial se aprovisiona de forma central es temporal en el mejor de los casos; la siguiente actualización de la política restaura el valor antiguo y el fallo vuelve sin explicación.
Verifique con un intento controlado
Actualice la entrada prevista, reconecte una vez y confirme que el túnel llega a algo concreto. Un intento controlado produce un error utilizable si falla, mientras que veinte producen una cuenta bloqueada y un misterio. Si un cliente sigue fallando después de corregir el almacén, capture un solo error sin secretos y deténgase. Guarde ese error con el nombre del dispositivo para que el siguiente turno empiece donde usted terminó.
Un cambio de contraseña no toca certificados, tokens de sesión ni el registro de MFA, y esas son identidades separadas con su propio ciclo de vida. Un certificado renovado no se arregla rotando una contraseña, y un token emitido antes del restablecimiento puede seguir siendo válido. Termine anotando qué almacén tenía el valor antiguo, porque el siguiente restablecimiento se topará con la misma lista.