Oprava chyby AnyConnect „nepodařilo se inicializovat podsystém připojení“
Selhání nastane dřív, než z počítače odejdou jakékoli přihlašovací údaje. Zkontrolujte službu agenta, příznak offline HTTP a poté Hyper-V nebo ICS, které drží adaptér.
Kliknete na Připojit a dialog odpoví téměř okamžitě: nepodařilo se inicializovat podsystém připojení. Ke bráně se nic nedostalo, takže na druhé straně neproběhla výměna certifikátu, nepřišly přihlašovací údaje a nevybrala se skupina tunelu. To znamená, že protokoly koncentrátoru ukážou prázdnou relaci a helpdesk bude žádat snímek dialogu, který nikdy nic užitečného neobsahoval. Pracujte raději na koncovém bodě, v pevném pořadí, a zastavte se u prvního kroku, který změní výsledek.
Časování je nejcennější důkaz, který máte, a jeho zaznamenání nic nestojí. Zapište, zda se chyba objevila před výzvou k zadání údajů, nebo po ní, a zda začala po upgradu, aktualizaci Windows nebo novém bezpečnostním agentovi. Tyto tři odpovědi obvykle zkrátí seznam kandidátů na polovinu, než se dotknete jakéhokoli nastavení.
Přečtěte si časování, než cokoli změníte
Tři místa selhání vypadají podobně a podobná nejsou. Pokud se dialog objeví v okamžiku stisku Připojit, klient nedokázal spustit vlastní infrastrukturu, a právě na to tento text poukazuje. Pokud se objeví po zadání údajů, skupina tunelu byla dosažena a problém je dál. Pokud se tunel zvedne a pak spadne, podsystém se inicializoval správně a vy honíte úplně jinou chybu. Záměna těchto tří případů stojí odpoledne na přeinstalacích, které nemohou pomoci.
Sem patří jen první případ. Zpráva vzniká dříve, než padne jakékoli síťové rozhodnutí, takže špatná adresa brány, propadlý certifikát nebo špatné heslo ji nevyvolají.
Krok 1: ověřte, že služba agenta běží
Okno, na které klikáte, je jen čelní rozhraní; práce probíhá ve službě Cisco AnyConnect Secure Mobility Agent, registrované jako vpnagent. Pokud je tato služba zastavená nebo zakázaná, grafické rozhraní nemá s kým mluvit a hlásí přesně toto selhání inicializace. Zkontrolujte stav a typ spouštění z příkazového řádku PowerShell se zvýšenými právy:
Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent
Instalátor, který respektoval dříve ručně nastavený typ spouštění, je obvyklým důvodem, proč to skončí zakázané, proto zkontrolujte StartType místo pouhého stisku Start. Pokud se služba spustí a během několika sekund zastaví, přečtěte si v protokolu System záznamy Service Control Manageru, než kliknete na Opravit:
Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40
Blokovaný ovladač, soubor v karanténě nebo filtrovací ovladač bezpečnostního produktu třetí strany se v těch událostech pojmenuje. Oprava přeinstaluje přes stejný blokovaný soubor a nic nezmění, a proto protokol událostí přichází první.
Krok 2: zrušte offline stav, který hlásí HTTP zásobník
Klient stahuje profil a vyhodnocuje zásady přes komponenty HTTP v Windows, takže příznak offline nastavený v internetovém nastavení uživatele může zlomit inicializaci, zatímco každý prohlížeč dál načítá stránky. Zkontrolujte hodnotu přímo:
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline
Hodnota 1 znamená, že zásobník WinINet sděluje volajícím, že počítač nemá připojení; tento stav obvykle nastavuje položka nabídky Pracovat offline v Internet Exploreru nebo automatizační skript. Vraťte ji na 0, odhlaste se a znovu přihlaste a připojení zkuste znovu, než změníte cokoli dalšího.
Pokud jste tento počítač zdědili a neumíte říct, proč byl příznak nastaven, poznamenejte to do tiketu. Něco jiného na počítači ho mohlo nastavit záměrně a při příštím přihlášení se vrátí.
Krok 3: uvolněte virtuální adaptér od Hyper-V nebo ICS
Dvě role Windows mohou držet části, které klient potřebuje k vytvoření adaptéru. Hyper-V je první: když běží služby virtuálního přepínače, vytvoření adaptéru může selhat způsoby, které se projeví jako tato chyba. Zastavení služeb je diagnostika, ne oprava:
Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"
Pokud se klient připojí se zastavenými službami, konflikt je potvrzen a nyní víte, o čem jednat s vlastníkem hostitele Hyper-V. Poté je restartujte, pokud počítač už virtualizaci nepotřebuje.
Sdílení připojení k internetu je druhým vlastníkem. Pokud se nějaké připojení sdílí, klient může selhat dřív, než vůbec vytvoří tunel. Ověřte pomocí Get-Service SharedAccess a pokud běží a je nastaveno na automaticky, projděte adaptéry a najděte sdílené připojení a vypněte sdílení jen na tomto adaptéru.
Existuje i levnější vysvětlení, které je třeba vyloučit jako první. Počítač bez jakéhokoli funkčního přístupu k internetu často zobrazí tuto zprávu místo chyby dostupnosti, proto ověřte, že Test-NetConnection k adrese brány i k veřejnému hostiteli uspěje, než obviníte klienta.
Ověřte a potom vraťte zpět, co nebylo potřeba
Ověření není zelený štít v oznamovací oblasti. Ověřte, že adaptér existuje, má adresu a propouští provoz: Get-NetAdapter -Name "Cisco AnyConnect*" by ho měl ukázat jako aktivní, ipconfig /all by měl ukázat přidělenou adresu a servery DNS a skutečný požadavek na interní jméno by se měl vyřešit tunelem, ne místním překladačem.
Veďte si krátký seznam každé změny, kterou provedete, s hodnotou, kterou jste našli, a hodnotou, kterou jste nastavili. Pokud připojení po třetím kroku funguje, obnovte služby Hyper-V a před uzavřením tiketu to znovu otestujte, protože obchvat, který tiše vypíná virtualizaci, zruší příští správce, který si toho všimne.
Pokud žádný ze tří kroků chybou nepohne, přestaňte koncový bod měnit. Sesbírejte verzi klienta, stav služby, časování z horní části této stránky a diagnostický balíček, který klient umí vytvořit, a předejte je s přesným pořadím, které jste zkusili. Ten balíček má pro dalšího inženýra větší cenu než snímek dialogu a je jediným artefaktem, který ukazuje, zda podsystém selhal předtím, nebo poté, co se dotkl sítě.