Исправление ошибки AnyConnect «не удалось инициализировать подсистему подключения»

Вы нажимаете «Подключиться», и диалог отвечает почти мгновенно: не удалось инициализировать подсистему подключения. До шлюза ничего не дошло, поэтому на другой стороне нет ни обмена сертификатами, ни учётных данных, ни выбора группы туннелей. Это значит, что журналы концентратора покажут пустой сеанс, а служба поддержки попросит снимок экрана диалога, в котором никогда не было ничего полезного. Работайте вместо этого с конечной точкой, в фиксированном порядке, и остановитесь на первом шаге, который изменит результат.

Время — самое ценное доказательство, которое у вас есть, и записать его ничего не стоит. Запишите, появилась ли ошибка до или после запроса учётных данных и началась ли она после обновления, обновления Windows или нового агента безопасности. Эти три ответа обычно вдвое сокращают список кандидатов ещё до того, как вы коснётесь любой настройки.

Прочитайте время, прежде чем что-либо менять

Три точки отказа выглядят одинаково и таковыми не являются. Если диалог появляется в момент нажатия «Подключиться», клиент не смог запустить собственную инфраструктуру, и именно на это указывает сообщение. Если он появляется после ввода учётных данных, группа туннелей достигнута, а проблема дальше. Если туннель поднимается и затем падает, подсистема инициализировалась правильно, и вы гонитесь за совсем другой ошибкой. Путаница между этими тремя стоит половины дня на переустановки, которые не могут помочь.

Сюда относится только первый случай. Сообщение формируется до любого сетевого решения, поэтому неверный адрес шлюза, истёкший сертификат или неверный пароль его не вызовут.

Шаг 1: убедитесь, что служба агента работает

Окно, на которое вы нажимаете, — лишь интерфейс; работа идёт в службе Cisco AnyConnect Secure Mobility Agent, зарегистрированной как vpnagent. Если эта служба остановлена или отключена, графическому интерфейсу не с кем разговаривать и он сообщает именно об этом сбое инициализации. Проверьте состояние и тип запуска из командной строки PowerShell с повышенными правами:

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

Установщик, уваживший ранее заданный вручную тип запуска, — обычная причина того, что служба оказывается отключённой, поэтому проверьте StartType, а не просто нажимайте «Запустить». Если служба запускается и останавливается за секунды, прочитайте журнал System на предмет записей Service Control Manager, прежде чем нажимать «Исправить»:

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

Заблокированный драйвер, файл в карантине или драйвер фильтра стороннего продукта безопасности назовёт себя в этих событиях. «Исправить» переустанавливает поверх того же заблокированного файла и ничего не меняет, поэтому журнал событий идёт первым.

Шаг 2: очистите автономное состояние, о котором сообщает стек HTTP

Клиент скачивает профиль и оценивает политику через компоненты HTTP Windows, поэтому флаг автономной работы в интернет-настройках пользователя может сломать инициализацию, хотя каждый браузер продолжает загружать страницы. Проверьте значение напрямую:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

Значение 1 означает, что стек WinINet сообщает вызывающим, что у машины нет подключения; обычно это состояние задаёт пункт меню «Работать автономно» в Internet Explorer или сценарий автоматизации. Верните его на 0, выйдите и войдите снова и повторите подключение, прежде чем менять что-то ещё.

Если эта машина досталась вам по наследству и вы не можете сказать, почему флаг был установлен, отметьте это в заявке. Что-то другое на машине могло задать его намеренно, и он вернётся при следующем входе.

Шаг 3: освободите виртуальный адаптер от Hyper-V или ICS

Две роли Windows могут удерживать части, которые нужны клиенту для создания адаптера. Hyper-V — первая: когда службы виртуального коммутатора работают, создание адаптера может завершиться неудачей так, что это проявляется данной ошибкой. Остановка служб — диагностика, а не исправление:

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

Если клиент подключается с остановленными службами, конфликт подтверждён, и теперь вы знаете, о чём договариваться с владельцем хоста Hyper-V. Перезапустите их после этого, если машине больше не нужна виртуализация.

Общий доступ к подключению к Интернету — второй владелец. Если какое-то подключение используется совместно, клиент может отказать ещё до создания туннеля. Подтвердите с помощью Get-Service SharedAccess и, если она работает и установлена на «автоматически», просмотрите адаптеры в поисках общего подключения и отключите общий доступ только на этом адаптере.

Есть и более дешёвое объяснение, которое нужно исключить первым. Машина без работающего доступа в интернет часто показывает это сообщение вместо ошибки доступности, поэтому убедитесь, что Test-NetConnection к адресу шлюза и к публичному хосту оба успешны, прежде чем винить клиент.

Проверьте, затем откатите то, что не понадобилось

Проверка — это не зелёный щит в области уведомлений. Убедитесь, что адаптер существует, имеет адрес и пропускает трафик: Get-NetAdapter -Name "Cisco AnyConnect*" должен показать его активным, ipconfig /all должен показать назначенный адрес и DNS-серверы, а реальный запрос к внутреннему имени должен разрешаться через туннель, а не через локальный резолвер.

Ведите короткий список каждого изменения с найденным и заданным значением. Если подключение работает после третьего шага, восстановите службы Hyper-V и перепроверьте, прежде чем закрывать заявку, потому что обходной путь, тихо отключающий виртуализацию, будет отменён следующим администратором, который это заметит.

Если ни один из трёх шагов не сдвигает ошибку, прекратите менять конечную точку. Соберите версию клиента, состояние службы, время из верхней части этой страницы и диагностический пакет, который клиент может создать, и передайте их вместе с точным порядком, который вы попробовали. Этот пакет для следующего инженера ценнее снимка экрана диалога, и это единственный артефакт, показывающий, отказала ли подсистема до или после обращения к сети.