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

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