Поправка на грешката на 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 и тестирајте повторно пред да го затворите тикетот, зашто заобиколното решение што тивко ја исклучува виртуелизацијата ќе го поништи следниот администратор што ќе го забележи.

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