AnyConnect перезаписує ваш профіль? Це збіг імен

Ходить історія, що AnyConnect загубив ваш другий шлюз або що клієнт надто старий, щоб тримати два профілі. Не сталося ні того, ні іншого. Сталося ось що: клієнт зберігає кожен побачений профіль як файл з іменем, яке надіслав сервер, а ваші два шлюзи називають свій файл однаково. На диску для цього імені є одне місце, тому друге завантаження займає місце першого.

Дві теки, і лише одна з них ваша

Копія, яка змінюється, — це робоча копія у вашому власному профілі користувача, зазвичай %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml. Цей файл записує останнє підключення і те, який профіль при ньому використовувався. Оскільки він лежить у вашій теці, клієнт перезаписує його при кожному підключенні, не запитуючи підвищення прав.

Список у спадному меню — це інше. Кожен профіль, який машина коли-небудь отримувала, копіюється до %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile, і клієнт показує файли, що там лежать. Запис у цю теку потребує прав адміністратора, що пояснює симптом, який люди читають неправильно: додавання профілю вручну як звичайний користувач виглядає працюючим, а потім запис зникає.

Отже, файл користувача — це вказівник, а тека всієї машини — бібліотека. Відсутній запис означає, що змінилася бібліотека, а не вказівник.

Клієнт зіставляє файли за іменем, а не за шлюзом

Ідентичність профілю в цьому клієнті — це ім'я файлу. Два пристрої, які обидва надсилають company.xml, з погляду локального сховища профілів — це той самий профіль, опублікований двічі. Друге завантаження перезаписує перше, а запис у вікні продовжує вказувати на один файл, який тепер описує інше місце.

Тому збій виглядає так дивно. Ім'я в списку й далі читається як місце, яке ви очікуєте, автентифікація й далі проходить на тому шлюзі, який справді налаштований, і ніщо не повідомляє про помилку. Змінився вміст за міткою, якій ви довіряли.

Читайте HostAddress, а не мітку

Відкрийте файл у текстовому редакторі й подивіться на список серверів. Профіль має елемент HostName — це мітка для показу, і елемент HostAddress — це шлюз, з яким клієнт справді зв'язується. Мітка — це довільний текст, який може змінити будь-хто, а адреса вирішує, куди ви потрапите.

Порівняйте ці два зі шлюзом, до якого ви хотіли потрапити, перш ніж вирішувати, що клієнт зламаний.

Зберегти обидва шлюзи, по порядку

Отримайте прийнятий профіль для кожного місця — або з самого місця, або з машини, яка вже підключається. Перейменуйте кожен файл так, щоб імена різнилися, наприклад site-a.xml і site-b.xml. Як адміністратор покладіть обидва в теку профілів усієї машини й збережіть отримані оригінали. Потім перезапустіть клієнт і переконайтеся, що обидва записи з'явилися у спадному меню.

Після підключення до кожного знову відкрийте preferences.xml і перевірте, яке ім'я профілю він тепер записує як останнє використане. Якщо ім'я збігається із записом, на який ви натиснули, локальне зіставлення працює правильно. Якщо ні, щось усе ще підкладає файл поверх вашої перейменованої копії.

Що перейменування не виправляє

Нове ім'я файлу змінює локальну мітку і більше нічого. Адреса шлюзу, метод автентифікації, сертифікат, який представляє сервер, і будь-який вибір групи всередині профілю залишаються такими, як були. Перейменована копія неправильного профілю — усе ще неправильний профіль, і вона підключить вас до неправильного місця під переконливим ім'ям.

Вона також не переживе керівний push, націлений на початкове ім'я файлу.

Коли наступний push це скасує

Якщо ваша організація розповсюджує профілі за іменем, оновлення замінить будь-який файл з цим іменем. Вважайте перейменовані копії локальною зручністю і повторюйте тест підключення після кожного оновлення клієнта, перевіряючи адресу, а не мітку.

Для постійного рішення попросіть підтримувану конфігурацію з кількома шлюзами замість ручного ведення файлів. Зміни в каталозі програми — перше, що видаляє оновлення, а файл користувацьких налаштувань перезаписується за задумом.

Тримайте один рядок на шлюз: ім'я файлу, HostAddress і тека, у якій він лежить. Ця нотатка відповість на наступне повідомлення про неправильне місце швидше, ніж переінсталяція.