¿AnyConnect sobrescribe tu perfil? Es una colisión de nombres
Dos puertas de enlace, un solo nombre de archivo: el cliente guarda el último perfil en tu carpeta mientras la biblioteca es de toda la máquina. Renombra las copias para conservar las dos.
La historia que circula es que AnyConnect perdió tu segunda puerta de enlace, o que el cliente es demasiado antiguo para mantener dos perfiles. No ocurrió ninguna de las dos cosas. Lo que ocurrió es que el cliente guarda cada perfil que ha visto como un archivo con el nombre que envió el servidor, y tus dos puertas de enlace llaman igual a su archivo. En el disco hay un solo sitio para ese nombre, así que la segunda descarga ocupa el sitio de la primera.
Dos carpetas, y solo una es tuya
La copia que cambia es la copia de trabajo bajo tu propio perfil de usuario, normalmente %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml. Ese archivo registra la última conexión que hiciste y qué perfil utilizó. Como vive en tu carpeta, el cliente lo reescribe en cada conexión sin pedir elevación.
La lista que ves en el desplegable es otra cosa. Cada perfil que la máquina ha recibido alguna vez se copia en %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile, y el cliente lista los archivos que haya allí. Escribir en esa carpeta requiere derechos de administrador, lo que explica un síntoma que la gente interpreta mal: añadir un perfil a mano como usuario normal parece funcionar, y luego la entrada desaparece.
Así que el archivo por usuario es un puntero y la carpeta de toda la máquina es la biblioteca. Una entrada que falta significa que cambió la biblioteca, no el puntero.
El cliente empareja archivos por nombre, no por puerta de enlace
La identidad del perfil en este cliente es el nombre del archivo. Dos dispositivos que ambos publican company.xml son, desde el punto de vista del almacén local de perfiles, el mismo perfil publicado dos veces. La segunda descarga sobrescribe la primera, y la entrada de la ventana sigue apuntando a un archivo que ahora describe el otro sitio.
Por eso el fallo parece tan extraño. El nombre de la lista se sigue leyendo como el lugar que esperas, la autenticación sigue teniendo éxito contra la puerta de enlace que realmente está configurada, y nada informa de un error. Lo que cambió es el contenido detrás de una etiqueta en la que confiabas.
Lee HostAddress, no la etiqueta
Abre el archivo en un editor de texto y mira la lista de servidores. Un perfil lleva un elemento HostName, que es una etiqueta de visualización, y un elemento HostAddress, que es la puerta de enlace con la que el cliente contacta realmente. La etiqueta es texto libre que cualquiera puede editar, y la dirección es lo que decide dónde acabas.
Compara esos dos con la puerta de enlace a la que querías llegar antes de concluir que el cliente está roto.
Conservar las dos puertas de enlace, en orden
Consigue el perfil aceptado de cada sitio, ya sea del sitio o de una máquina que ya conecta. Renombra cada archivo para que los dos nombres difieran, por ejemplo site-a.xml y site-b.xml. Como administrador, coloca ambos en la carpeta de perfiles de toda la máquina y guarda los originales que recibiste. Luego reinicia el cliente y confirma que ambas entradas aparecen en el desplegable.
Después de conectarte a cada una, vuelve a abrir preferences.xml y comprueba qué nombre de perfil registra ahora como último usado. Si el nombre coincide con la entrada en la que hiciste clic, el mapeo local se comporta bien. Si no, algo sigue enviando un archivo sobre tu copia renombrada.
Qué no arregla renombrar
Un nombre de archivo nuevo cambia una etiqueta local y nada más. La dirección de la puerta de enlace, el método de autenticación, el certificado que presenta el servidor y cualquier selección de grupo dentro del perfil se quedan como estaban. Una copia renombrada del perfil equivocado sigue siendo el perfil equivocado, y te conectará al sitio equivocado bajo un nombre convincente.
Tampoco sobrevive a un envío de gestión dirigido al nombre de archivo original.
Cuando el siguiente envío lo deshace
Si tu organización distribuye perfiles por nombre, una actualización sustituye cualquier archivo que comparta ese nombre. Trata las copias renombradas como una comodidad local y repite la prueba de conexión tras cada actualización del cliente, mirando la dirección y no la etiqueta.
Para un arreglo permanente, pide una configuración de varias puertas de enlace compatible en lugar de mantener archivos a mano. Las ediciones dentro del directorio del programa son lo primero que elimina una actualización, y el archivo de preferencias por usuario se reescribe por diseño.
Mantén una línea por puerta de enlace: nombre del archivo, HostAddress y en qué carpeta vive. Esa nota responde al siguiente informe de sitio equivocado más rápido que una reinstalación.