Desbloqueas el Mac, abres el cliente VPN y aparece una hoja de contraseña antes de que el túnel haya empezado. Escribes la contraseña de la puerta de enlace y o bien la rechazan o bien la hoja vuelve un momento después. Luego vuelve a preguntar tras despertar del reposo, cerrar sesión o una actualización del cliente. Esa hoja rara vez es el servidor VPN pidiendo credenciales; normalmente macOS pide permiso para leer, desbloquear o cambiar un registro local, y la contraseña pertenece al dueño de ese registro, no a tu cuenta de VPN.

Empareja la hoja con la identidad que hay detrás

Cuatro avisos parecen casi idénticos y solo uno afecta a la puerta de enlace. La redacción, el proceso que solicita acceso y el elemento nombrado debajo te dicen cuál tienes delante.

What the sheet saysWhose password it wantsWhat it does not do
Enter the password for the login keychainThe local keychain password, normally your Mac login passwordIt does not authenticate you to the VPN server
An app wants to use confidential information stored in your keychainApproval for that app to retrieve one itemIt does not grant privileges at the gateway
macOS wants to make changes, and asks for administrator authorizationAn admin account on this Mac, for the named settingIt does not change the VPN account password
The client itself asks for a username and password to connectThe remote account, certificate or profile credentialIt does not unlock anything local

Un diálogo sobre acceso local no demuestra nada sobre el servidor. Un rechazo de la puerta de enlace aparece dentro del cliente con el texto de error del proveedor, no como una hoja del sistema que ofrece desbloquear un llavero. Lo contrario es igual de frecuente: escribir la contraseña de la puerta de enlace en una hoja del llavero deja el registro bloqueado y suma un intento fallido.

El diálogo nombra un dueño, un almacén y una acción

Los avisos del llavero tratan de recuperar, no de autenticarse ante algo remoto. La descripción de Apple del diálogo de solicitud es estrecha: Permitir una vez, Permitir siempre y Denegar controlan si esa app puede leer el elemento guardado. Ninguna de las tres concede un privilegio en la puerta de enlace ni cambia lo que el servidor piensa de tu contraseña.

Cuando el solicitante es un cliente recién actualizado, es de esperar una nueva aprobación: la compilación nueva ya no coincide con la lista de control de acceso del elemento, así que macOS vuelve a preguntar. Responde Permitir una vez mientras diagnosticas. Permitir siempre es una concesión permanente a esa app y la respuesta equivocada para un proceso auxiliar que no esperabas; deniega y comprueba al proveedor si el binario no es el cliente que instalaste.

Un aviso que pide autorización de administrador es otra cosa. Nombra un ajuste del sistema o un almacén protegido que se está cambiando, y la credencial que quiere es una cuenta de administrador en este Mac. No todos los elementos personales del llavero lo necesitan; los que están detrás de la configuración de red normalmente sí, porque la configuración pertenece al sistema, no a tu sesión de inicio.

Dónde puede vivir una contraseña de VPN en un Mac

El llavero es un almacén posible, no la definición de un almacén. Una configuración de VPN integrada creada en Ajustes del Sistema guarda sus credenciales con la configuración de red, como un ajuste del sistema gestionado. Un cliente de terceros suele guardar un elemento en tu llavero de inicio de sesión: una contraseña genérica con clave por nombre de servicio o una contraseña de internet con clave por servidor, protocolo y cuenta. Muchas apps más nuevas usan en su lugar el llavero de protección de datos, cuyos elementos nunca aparecen en Acceso a Llaveros.

La gente busca el nombre de la VPN en Acceso a Llaveros, no encuentra nada y concluye que la contraseña no está guardada. La nota TN3137 de Apple dice que existe más de una implementación de llavero; la ausencia en esa lista es normal, no prueba de un elemento roto.

Los tipos de registro tampoco son intercambiables. Una contraseña de cuenta, una frase de paso de clave privada, un certificado de cliente y un secreto compartido de IPsec fallan de forma distinta y se reparan en lugares distintos; volver a escribir una contraseña guardada no hace nada por un certificado rechazado. Si el Mac está inscrito en gestión, el perfil es otro dueño: una carga de VPN puede llevar credenciales y reaplicarlas al refrescar, así que borrar un elemento local es temporal hasta que un administrador lo cambie.

Cuando la contraseña de inicio y la del llavero se separan

El llavero de inicio usa normalmente tu contraseña de inicio del Mac, por eso las dos pueden separarse. Que un administrador restablezca tu contraseña desde otra cuenta, un flujo de recuperación o un cambio de directorio pueden dejar el llavero bloqueado con el valor antiguo, y entonces macOS pide una contraseña que no acabas de definir.

Al iniciar sesión puedes ver un aviso de que el sistema no pudo desbloquear el llavero. Actualizarlo necesita la contraseña antigua, lo que va bien si la recuerdas y es inútil si no. Las dos reparaciones honestas son Acceso a Llaveros, Editar, Cambiar contraseña del llavero "login", o un llavero de inicio nuevo con las credenciales necesarias vueltas a introducir. La segunda opción destruye los elementos guardados.

No restablezcas todo el llavero porque una VPN rechaza una credencial antigua: eso elimina cuentas no relacionadas y sigue sin identificar el elemento.

Un comando resuelve la cuestión de local contra remoto. Pide el elemento directamente al llavero:

security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -g

Usa el servidor y la cuenta de los ajustes de tu cliente. Si la misma hoja de aprobación aparece cuando preguntas tú mismo al llavero, el aviso es local y el servidor es un espectador. Si no existe tal elemento, el cliente no guarda la contraseña donde suponías. El indicador -g imprime el secreto en la terminal, así que evita compartir pantalla.

Actualiza el registro que el cliente lee de verdad

Si la cuenta cambió en la puerta de enlace, cámbiala primero allí y luego actualiza el registro guardado mediante los ajustes del cliente. Editar a mano un elemento del llavero no es fiable: el cliente puede leer otro par de servicio y cuenta, y un perfil gestionado sobrescribirá tu edición.

Para un elemento que sospechas obsoleto, empareja servicio, cuenta y protocolo antes de borrar nada:

security delete-generic-password -s "Client Name" -a [email protected]

Borrar un elemento de nombre parecido de otra conexión es una interrupción frecuente que te provocas tú mismo. La eliminación solo es local: no revoca una sesión en la puerta de enlace, no desvincula un certificado de dispositivo ni cambia la contraseña de la cuenta.

Confirma que la reparación sobrevive a un reinicio

Conéctate, despierta del reposo, cierra y vuelve a abrir sesión y reinicia una vez. Una secuencia limpia sin hoja y un estado del cliente que nombre la cuenta esperada es la única prueba que cuenta. Donde vuelve el aviso te dice qué capa te saltaste: tras una actualización es la aprobación, tras un cambio de red el aviso propio del cliente, tras un reinicio un perfil que reaplica estado.

Revisa en el cliente si hay un ajuste de recordar contraseña o preguntar siempre antes de tocar el llavero otra vez. Algunas configuraciones, sobre todo IKEv2 con autenticación por usuario, preguntan por diseño en cada conexión; la reparación del llavero no ayudará.

Anota qué elemento cambiaste, qué almacén lo poseía y a qué cuenta pertenecía, para que el siguiente aviso se ubique en segundos. La página de Apple Solicitudes de acceso al llavero es la referencia sobre qué autorizan esos tres botones.

Artículos relacionados