Историята, която се разпространява, е, че 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 и проверете кое име на профил записва сега като последно използвано. Ако името съвпада със записа, който сте щракнали, локалното съпоставяне работи правилно. Ако не, нещо все още изпраща файл върху преименуваното ви копие.

Какво не поправя преименуването

Новото име на файл променя локален етикет и нищо друго. Адресът на шлюза, методът за удостоверяване, сертификатът, който сървърът представя, и всеки избор на група в профила остават каквито са били. Преименувано копие на грешния профил все още е грешният профил и ще ви свърже с грешния сайт под убедително име.

То също не издържа на управлявано изпращане, насочено към оригиналното име на файла.

Когато следващото изпращане го отмени

Ако организацията ви разпространява профили по име, актуализацията заменя всеки файл с това име. Приемайте преименуваните копия като локално удобство и повтаряйте теста за свързване след всяка актуализация на клиента, като проверявате адреса, а не етикета.

За трайно решение поискайте поддържана настройка с няколко шлюза вместо ръчно поддържане на файлове. Промените в програмната папка са първото, което актуализацията премахва, а файлът с предпочитания на потребителя се презаписва по замисъл.

Дръжте по един ред за шлюз: име на файла, HostAddress и в коя папка се намира. Тази бележка отговаря на следващия доклад за грешен сайт по-бързо от преинсталиране.

Подобни статии