Az AnyConnect „nem sikerült inicializálni a kapcsolat alrendszerét“ hiba javítása
A hiba azelőtt történik, hogy bármilyen hitelesítő adat elhagyná a gépet. Ellenőrizze az ügynökszolgáltatást, az offline HTTP jelzőt, majd a Hyper-V vagy az ICS adapterfoglalását.
Rákattint a Kapcsolódás gombra, és a párbeszédablak szinte azonnal válaszol: nem sikerült inicializálni a kapcsolat alrendszerét. Semmi nem ért el az átjáróhoz, így nincs tanúsítványcsere, nincs hitelesítő adat, és nincs alagútcsoport-választás a másik oldalon. Ez azt jelenti, hogy a koncentrátor naplói üres munkamenetet mutatnak, az ügyfélszolgálat pedig egy olyan párbeszédablak képernyőképét kéri, amely soha nem tartalmazott semmi hasznosat. Dolgozzon inkább a végponton, rögzített sorrendben, és álljon meg az első lépésnél, amely megváltoztatja az eredményt.
Az időzítés a legértékesebb bizonyíték, amellyel rendelkezik, és rögzítése semmibe sem kerül. Jegyezze fel, hogy a hiba a hitelesítő adatok kérése előtt vagy után jelent meg, és hogy frissítés, Windows-frissítés vagy új biztonsági ügynök után kezdődött-e. Ez a három válasz általában a felére csökkenti a jelöltek listáját, mielőtt bármilyen beállításhoz hozzányúlna.
Olvassa el az időzítést, mielőtt bármit megváltoztat
Három hibahely hasonlónak tűnik, és nem az. Ha a párbeszédablak a Kapcsolódás megnyomásának pillanatában jelenik meg, az ügyfél nem tudta elindítani a saját infrastruktúráját, és erre mutat ez az üzenet. Ha a hitelesítő adatok beírása után jelenik meg, az alagútcsoportot elérték, és a probléma távolabb van. Ha az alagút feljön, majd leesik, az alrendszer megfelelően inicializálódott, és egészen más hiba után kutat. A három összekeverése egy délutánt pazarol olyan újratelepítésekre, amelyek nem segíthetnek.
Ide csak az első eset tartozik. Az üzenet minden hálózati döntés előtt keletkezik, ezért rossz átjárócím, lejárt tanúsítvány vagy rossz jelszó nem hozza létre.
1. lépés: ellenőrizze, hogy fut az ügynökszolgáltatás
Az ablak, amelyre kattint, csak homlokzat; a munka a Cisco AnyConnect Secure Mobility Agent szolgáltatásban történik, amely vpnagent néven van regisztrálva. Ha ez a szolgáltatás le van állítva vagy le van tiltva, a grafikus felületnek nincs kivel beszélnie és pontosan ezt az inicializálási hibát jelenti. Ellenőrizze az állapotot és az indítási típust egy emelt szintű PowerShell-parancssorból:
Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent
Az a telepítő, amely tiszteletben tartott egy korábban kézzel beállított indítási típust, a szokásos oka annak, hogy ez letiltva végződik, ezért ellenőrizze a StartType értékét ahelyett, hogy csak az Indítás gombot nyomná meg. Ha a szolgáltatás másodperceken belül elindul és leáll, olvassa el a System naplóban a Service Control Manager bejegyzéseit, mielőtt a Javítás gombra kattint:
Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40
Egy blokkolt illesztőprogram, egy karanténba tett fájl vagy egy harmadik féltől származó biztonsági termék szűrőillesztőprogramja megnevezi magát ezekben az eseményekben. A Javítás ugyanarra a blokkolt fájlra telepít újra, és semmit nem változtat, ezért jön előbb az eseménynapló.
2. lépés: törölje az offline állapotot, amelyet a HTTP verem jelent
Az ügyfél letölti a profilját, és Windows HTTP-összetevőkön keresztül értékeli a házirendet, ezért a felhasználó internetbeállításaiban beállított offline jelző megtörheti az inicializálást, miközben minden böngésző tovább tölti az oldalakat. Ellenőrizze az értéket közvetlenül:
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline
A 1 érték azt jelenti, hogy a WinINet verem azt közli a hívókkal, hogy a gépnek nincs kapcsolata; ezt az állapotot általában az Internet Explorer Offline munka menüpontja vagy egy automatizálási parancsfájl állítja be. Állítsa vissza 0-ra, jelentkezzen ki és be újra, és próbálja újra a kapcsolatot, mielőtt bármi mást megváltoztatna.
Ha örökölte ezt a gépet, és nem tudja megmondani, miért állították be a jelzőt, jegyezze fel a jegybe. Valami más a gépen szándékosan beállíthatta, és a következő bejelentkezéskor visszatér.
3. lépés: szabadítsa fel a virtuális adaptert a Hyper-V vagy az ICS alól
Két Windows-szerepkör is fogva tarthatja azokat a darabokat, amelyekre az ügyfélnek az adaptere létrehozásához szüksége van. A Hyper-V az első: a virtuális kapcsoló szolgáltatásainak futása mellett az adapter létrehozása olyan módon hiúsulhat meg, amely ebben a hibában jelenik meg. A szolgáltatások leállítása diagnózis, nem javítás:
Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"
Ha az ügyfél ezekkel a szolgáltatásokkal leállítva csatlakozik, az ütközés megerősítést nyert, és most már tudja, miről kell tárgyalnia a Hyper-V gazdagép tulajdonosával. Indítsa újra őket utána, kivéve, ha a gépnek már nincs szüksége virtualizációra.
Az internetkapcsolat megosztása a második tulajdonos. Ha egy kapcsolat meg van osztva, az ügyfél még azelőtt meghiúsulhat, hogy alagutat hozna létre. Erősítse meg a Get-Service SharedAccess paranccsal, és ha fut és automatikusra van állítva, nézze át az adaptereket megosztott kapcsolat után kutatva, és csak azon az adapteren kapcsolja ki a megosztást.
Van egy olcsóbb magyarázat is, amelyet először ki kell zárni. Egy gép, amelynek egyáltalán nincs működő internetelérése, gyakran ezt az üzenetet mutatja elérhetőségi hiba helyett, ezért erősítse meg, hogy a Test-NetConnection az átjáró címére és egy nyilvános gazdagépre is sikeres, mielőtt az ügyfelet hibáztatná.
Ellenőrizze, majd vonja vissza, amire nem volt szükség
Az ellenőrzés nem a tálca zöld pajzsa. Erősítse meg, hogy az adapter létezik, címet tart és forgalmat enged át: Get-NetAdapter -Name "Cisco AnyConnect*" aktívként kell mutatnia, ipconfig /all a hozzárendelt címet és a DNS-kiszolgálókat kell mutatnia, és egy belső névre irányuló valódi kérésnek az alagúton keresztül kell feloldódnia, nem a helyi feloldón.
Vezessen rövid listát minden változtatásról, a talált és a beállított értékkel. Ha a kapcsolat a harmadik lépés után működik, állítsa vissza a Hyper-V szolgáltatásokat, és teszteljen újra, mielőtt lezárja a jegyet, mert a virtualizációt csendben kikapcsoló kerülő megoldást a következő rendszergazda, aki észreveszi, visszavonja.
Ha a három lépés egyike sem mozdítja el a hibát, hagyja abba a végpont módosítását. Gyűjtse össze az ügyfél verzióját, a szolgáltatás állapotát, az oldal tetején szereplő időzítést és azt a diagnosztikai csomagot, amelyet az ügyfél elő tud állítani, majd adja át ezeket a pontos sorrenddel, amelyet kipróbált. Az a csomag többet ér a következő mérnöknek, mint a párbeszédablak képernyőképe, és ez az egyetlen olyan termék, amely megmutatja, hogy az alrendszer a hálózat megérintése előtt vagy után hibázott.