Ayusin ang AnyConnect error na „nabigo ang pagsisimula ng subsystem ng koneksyon“

Nag-click ka ng Kumonekta at sumasagot agad ang dialog: nabigo ang pagsisimula ng subsystem ng koneksyon. Walang nakarating sa gateway, kaya walang palitan ng sertipiko, walang kredensyal at walang pagpili ng tunnel group sa kabilang dulo. Ibig sabihin, magpapakita ang mga log ng concentrator ng walang laman na session at hihingi ang help desk ng screenshot ng dialog na kailanman ay walang kapaki-pakinabang na nilalaman. Gawin ang endpoint sa halip, sa isang takdang pagkakasunod-sunod, at huminto sa unang hakbang na nagbabago ng resulta.

Ang oras ang pinakamahalagang ebidensya na mayroon ka, at walang gastos ang itala ito. Isulat kung ang error ay lumitaw bago o pagkatapos ng kahilingan ng kredensyal, at kung nagsimula ito pagkatapos ng upgrade, update ng Windows o bagong security agent. Ang tatlong sagot na iyon ay kadalasang naghahati sa listahan ng mga kandidato bago mo pa hawakan ang anumang setting.

Basahin ang oras bago baguhin ang anuman

Tatlong punto ng kabiguan ang magkamukha at hindi magkapareho. Kung lumitaw ang dialog sa sandaling pinindot mo ang Kumonekta, hindi naisimulan ng client ang sarili nitong imprastraktura, at iyon ang itinuturo ng mensaheng ito. Kung lumitaw ito pagkatapos mong i-type ang kredensyal, naabot na ang tunnel group at mas malayo pa ang problema. Kung tumaas ang tunnel at pagkatapos ay bumagsak, maayos na naisimulan ang subsystem at ibang bug ang hinahabol mo. Ang paghahalo ng tatlo ay nagsasayang ng isang hapon sa mga muling pag-install na hindi makakatulong.

Ang unang kaso lamang ang nabibilang dito. Ang mensahe ay nabuo bago ang anumang desisyon sa network, kaya ang maling address ng gateway, nag-expire na sertipiko o masamang password ay hindi ito bubuo.

Hakbang 1: tiyakin na tumatakbo ang serbisyo ng agent

Ang window na kinlick mo ay harap lamang; ang trabaho ay nangyayari sa serbisyong Cisco AnyConnect Secure Mobility Agent, na nakarehistro bilang vpnagent. Kung ang serbisyong iyon ay nakatigil o naka-disable, walang makakausap ang GUI at iniuulat nito nang eksakto ang kabiguan sa pagsisimula. Suriin ang estado at uri ng pagsisimula mula sa elevated na PowerShell prompt:

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

Isang installer na gumalang sa dating manu-manong itinakdang uri ng pagsisimula ang karaniwang dahilan kung bakit ito nauuwi sa naka-disable, kaya suriin ang StartType sa halip na pindutin lang ang Start. Kung magsisimula at titigil ang serbisyo sa loob ng ilang segundo, basahin ang System log para sa mga entry ng Service Control Manager bago i-click ang Repair:

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

Isang naka-block na driver, file na nasa quarantine o filter driver mula sa security product ng third party ang magsasabi ng sarili nitong pangalan sa mga event na iyon. Ang Repair ay nag-i-install muli sa ibabaw ng parehong naka-block na file at walang binabago, kaya nauuna ang event log.

Hakbang 2: linisin ang offline na estado na iniuulat ng HTTP stack

Dinodownload ng client ang profile nito at sinusuri ang patakaran sa pamamagitan ng mga component ng HTTP ng Windows, kaya ang offline flag na itinakda sa mga setting ng internet ng user ay maaaring sirain ang pagsisimula habang naglo-load pa rin ng mga pahina ang bawat browser. Suriin ang halaga nang direkta:

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

Ang halagang 1 ay nangangahulugang sinasabi ng WinINet stack sa mga tumatawag na walang koneksyon ang makina; ang estadong ito ay karaniwang itinakda ng menu item na Work Offline sa Internet Explorer o ng automation script. Itakda itong muli sa 0, mag-sign out at mag-sign in muli, at subukan muli ang koneksyon bago baguhin ang anumang iba.

Kung namana mo ang makinang ito at hindi mo masabi kung bakit itinakda ang flag, itala ito sa ticket. May iba pang bagay sa makina na maaaring sadyang nagtakda nito, at babalik ito sa susunod na pag-log on.

Hakbang 3: palayain ang virtual adapter mula sa Hyper-V o ICS

Dalawang role ng Windows ang maaaring humawak sa mga pirasong kailangan ng client upang gawin ang adapter nito. Ang Hyper-V ang una: kapag tumatakbo ang mga serbisyo ng virtual switch, maaaring mabigo ang paggawa ng adapter sa mga paraang lumalabas bilang error na ito. Ang paghinto sa mga serbisyo ay diagnosis, hindi pagwawasto:

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

Kung kumokonekta ang client habang nakatigil ang mga serbisyong iyon, kumpirmado ang salungatan at alam mo na ngayon kung ano ang tawaran sa may-ari ng host ng Hyper-V. Simulan muli ang mga ito pagkatapos, maliban kung hindi na kailangan ng makina ang virtualization.

Ang Internet Connection Sharing ang pangalawang may-ari. Kung may koneksyong ibinabahagi, maaaring mabigo ang client bago pa man ito gumawa ng tunnel. Kumpirmahin gamit ang Get-Service SharedAccess at, kung tumatakbo ito at nakatakda sa automatic, tingnan ang mga adapter para sa shared na koneksyon at patayin ang pagbabahagi sa adapter na iyon lamang.

May mas murang paliwanag ding dapat unang alisin. Ang makina na walang gumaganang access sa internet ay madalas na nagpapakita ng mensaheng ito sa halip na error sa maabot, kaya tiyakin na Test-NetConnection sa address ng gateway at sa isang pampublikong host ay parehong nagtagumpay bago sisihin ang client.

I-verify, pagkatapos ay ibalik ang hindi mo kailangan

Ang verification ay hindi ang berdeng kalasag sa tray. Tiyakin na umiiral ang adapter, may address at nagpapadala ng trapiko: Get-NetAdapter -Name "Cisco AnyConnect*" dapat ipakita itong aktibo, ipconfig /all dapat ipakita ang itinalagang address at mga DNS server, at ang tunay na kahilingan sa isang panloob na pangalan ay dapat malutas sa pamamagitan ng tunnel at hindi ng lokal na resolver.

Magtago ng maikling listahan ng bawat pagbabago, kasama ang halagang natagpuan at ang halagang itinakda. Kung gumana ang koneksyon pagkatapos ng ikatlong hakbang, ibalik ang mga serbisyo ng Hyper-V at muling subukan bago isara ang ticket, dahil ang isang workaround na tahimik na nag-disable ng virtualization ay babalik ng susunod na administrator na makakapansin.

Kung wala sa tatlong hakbang ang gumagalaw sa error, itigil ang pagbabago sa endpoint. Kolektahin ang bersyon ng client, estado ng serbisyo, oras mula sa itaas ng pahinang ito at ang diagnostic bundle na kayang gawin ng client, pagkatapos ay ibigay ang mga ito kasama ang eksaktong pagkakasunod-sunod na sinubukan mo. Ang bundle na iyon ay mas mahalaga sa susunod na inhinyero kaysa sa screenshot ng dialog, at ito ang tanging artifact na nagpapakita kung nabigo ang subsystem bago o pagkatapos nitong mahawakan ang network.