Remedierea erorii AnyConnect „nu s-a putut inițializa subsistemul de conexiune“

Faceți clic pe Conectare și dialogul răspunde aproape instantaneu: nu s-a putut inițializa subsistemul de conexiune. Nimic nu a ajuns la gateway, deci nu există schimb de certificate, nicio acreditare și nicio selecție de grup de tunel la celălalt capăt. Asta înseamnă că jurnalele concentratorului vor arăta o sesiune goală, iar serviciul de asistență va cere o captură de ecran a unui dialog care nu a conținut niciodată ceva util. Lucrați în schimb pe punctul final, într-o ordine fixă, și opriți-vă la primul pas care schimbă rezultatul.

Momentul este cea mai valoroasă dovadă pe care o aveți, iar notarea lui nu costă nimic. Notați dacă eroarea a apărut înainte sau după solicitarea acreditărilor și dacă a început după o actualizare, o actualizare Windows sau un agent de securitate nou. Aceste trei răspunsuri reduc de obicei la jumătate lista candidaților înainte să atingeți vreo setare.

Citiți momentul înainte de a schimba ceva

Trei puncte de defecțiune arată la fel și nu sunt. Dacă dialogul apare în momentul în care apăsați Conectare, clientul nu a putut porni propria infrastructură, iar la asta indică acest mesaj. Dacă apare după ce tastați acreditările, grupul de tunel a fost atins și problema este mai departe. Dacă tunelul urcă și apoi cade, subsistemul s-a inițializat corect și urmăriți o cu totul altă eroare. Confundarea celor trei pierde o după-amiază cu reinstalări care nu pot ajuta.

Aici se încadrează doar primul caz. Mesajul este generat înainte de orice decizie de rețea, așa că o adresă de gateway greșită, un certificat expirat sau o parolă rea nu îl vor produce.

Pasul 1: confirmați că serviciul agentului rulează

Fereastra pe care faceți clic este doar partea frontală; munca are loc în serviciul Cisco AnyConnect Secure Mobility Agent, înregistrat ca vpnagent. Dacă acel serviciu este oprit sau dezactivat, interfața grafică nu are cu cine vorbi și raportează exact această defecțiune de inițializare. Verificați starea și tipul de pornire dintr-un prompt PowerShell ridicat:

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

Un program de instalare care a respectat un tip de pornire setat manual anterior este motivul obișnuit pentru care acesta ajunge dezactivat, așa că verificați StartType în loc să apăsați doar Start. Dacă serviciul pornește și se oprește în câteva secunde, citiți jurnalul System pentru intrări Service Control Manager înainte de a face clic pe Reparare:

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

Un driver blocat, un fișier în carantină sau un driver de filtru de la un produs de securitate terț își va spune numele în acele evenimente. Reparare reinstalează peste același fișier blocat și nu schimbă nimic, de aceea jurnalul de evenimente vine primul.

Pasul 2: ștergeți starea offline raportată de stiva HTTP

Clientul descarcă profilul și evaluează politica prin componentele HTTP din Windows, așa că un indicator offline setat în setările de internet ale utilizatorului poate rupe inițializarea în timp ce fiecare browser încarcă în continuare pagini. Verificați valoarea direct:

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

O valoare de 1 înseamnă că stiva WinINet le spune apelanților că mașina nu are conexiune; această stare este setată de obicei de elementul de meniu Lucrați offline din Internet Explorer sau de un script de automatizare. Setați-o înapoi la 0, deconectați-vă și reconectați-vă, și reîncercați conexiunea înainte de a schimba orice altceva.

Dacă ați moștenit această mașină și nu puteți spune de ce a fost setat indicatorul, notați asta în tichet. Altceva de pe mașină l-ar fi putut seta intenționat, iar el va reveni la următoarea autentificare.

Pasul 3: eliberați adaptorul virtual de Hyper-V sau ICS

Două roluri Windows pot ține piesele de care clientul are nevoie pentru a-și crea adaptorul. Hyper-V este primul: când serviciile comutatorului virtual rulează, crearea adaptorului poate eșua în moduri care se manifestă ca această eroare. Oprirea serviciilor este un diagnostic, nu o remediere:

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

Dacă clientul se conectează cu acele servicii oprite, conflictul este confirmat și acum știți despre ce să negociați cu proprietarul gazdei Hyper-V. Reporniți-le după aceea, dacă mașina nu mai are nevoie de virtualizare.

Partajarea conexiunii la internet este al doilea proprietar. Dacă o conexiune este partajată, clientul poate eșua înainte de a crea măcar un tunel. Confirmați cu Get-Service SharedAccess și, dacă rulează și este setat pe automat, parcurgeți adaptoarele pentru o conexiune partajată și dezactivați partajarea doar pe acel adaptor.

Există și o explicație mai ieftină de eliminat mai întâi. O mașină fără acces funcțional la internet afișează adesea acest mesaj în locul unei erori de accesibilitate, așa că confirmați că Test-NetConnection către adresa gatewayului și către o gazdă publică reușesc ambele înainte de a da vina pe client.

Verificați, apoi anulați ce nu a fost necesar

Verificarea nu este scutul verde din tavă. Confirmați că adaptorul există, are o adresă și lasă traficul să treacă: Get-NetAdapter -Name "Cisco AnyConnect*" ar trebui să îl arate activ, ipconfig /all ar trebui să arate adresa atribuită și serverele DNS, iar o cerere reală către un nume intern ar trebui rezolvată prin tunel, nu prin resolverul local.

Țineți o listă scurtă a fiecărei modificări, cu valoarea găsită și valoarea setată. Dacă conexiunea funcționează după al treilea pas, restaurați serviciile Hyper-V și retestați înainte de a închide tichetul, pentru că o soluție ocolitoare care dezactivează în tăcere virtualizarea va fi anulată de următorul administrator care observă.

Dacă niciunul dintre cei trei pași nu mișcă eroarea, opriți modificarea punctului final. Adunați versiunea clientului, starea serviciului, momentul din partea de sus a acestei pagini și pachetul de diagnostic pe care clientul îl poate produce, apoi predați-le cu ordinea exactă pe care ați încercat-o. Acel pachet valorează mai mult pentru următorul inginer decât o captură a dialogului și este singurul artefact care arată dacă subsistemul a eșuat înainte sau după ce a atins rețeaua.