Naprawa błędu AnyConnect „nie udało się zainicjować podsystemu połączenia“
Awaria następuje, zanim jakiekolwiek dane logowania opuszczą komputer. Sprawdź usługę agenta, flagę HTTP w trybie offline, a potem Hyper-V lub ICS trzymające adapter.
Klikasz Połącz, a okno odpowiada niemal natychmiast: nie udało się zainicjować podsystemu połączenia. Nic nie dotarło do bramy, więc po drugiej stronie nie ma wymiany certyfikatów, danych logowania ani wyboru grupy tuneli. Oznacza to, że dzienniki koncentratora pokażą pustą sesję, a pomoc techniczna poprosi o zrzut ekranu okna, które nigdy nie zawierało nic użytecznego. Pracuj zamiast tego na punkcie końcowym, w ustalonej kolejności, i zatrzymaj się na pierwszym kroku, który zmieni wynik.
Czas jest najcenniejszym dowodem, jaki masz, a jego zapisanie nic nie kosztuje. Zapisz, czy błąd pojawił się przed czy po monicie o dane logowania oraz czy zaczął się po aktualizacji, aktualizacji Windows lub nowym agencie zabezpieczeń. Te trzy odpowiedzi zwykle o połowę skracają listę kandydatów, zanim dotkniesz jakiegokolwiek ustawienia.
Przeczytaj czas, zanim cokolwiek zmienisz
Trzy punkty awarii wyglądają podobnie i nie są takie same. Jeśli okno pojawia się w chwili naciśnięcia Połącz, klient nie zdołał uruchomić własnej infrastruktury i na to wskazuje ten komunikat. Jeśli pojawia się po wpisaniu danych logowania, grupa tuneli została osiągnięta, a problem jest dalej. Jeśli tunel wstaje i potem spada, podsystem zainicjował się poprawnie i gonisz zupełnie inny błąd. Pomylenie tych trzech przypadków kosztuje popołudnie na reinstalacjach, które nie mogą pomóc.
Tylko pierwszy przypadek należy tutaj. Komunikat powstaje przed jakąkolwiek decyzją sieciową, więc błędny adres bramy, wygasły certyfikat lub złe hasło go nie wywołają.
Krok 1: potwierdź, że usługa agenta działa
Okno, w które klikasz, to tylko interfejs; praca odbywa się w usłudze Cisco AnyConnect Secure Mobility Agent, zarejestrowanej jako vpnagent. Jeśli ta usługa jest zatrzymana lub wyłączona, interfejs graficzny nie ma z kim rozmawiać i zgłasza dokładnie tę awarię inicjalizacji. Sprawdź stan i typ uruchomienia z wiersza PowerShell z podwyższonymi uprawnieniami:
Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent
Instalator, który uszanował wcześniej ustawiony ręcznie typ uruchomienia, jest zwykłą przyczyną tego, że usługa kończy jako wyłączona, więc sprawdź StartType zamiast tylko naciskać Start. Jeśli usługa startuje i zatrzymuje się w kilka sekund, przeczytaj dziennik System pod kątem wpisów Service Control Manager, zanim klikniesz Napraw:
Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40
Zablokowany sterownik, plik w kwarantannie lub sterownik filtra produktu zabezpieczeń innej firmy wskaże siebie w tych zdarzeniach. Naprawa instaluje ponownie na tym samym zablokowanym pliku i niczego nie zmienia, dlatego dziennik zdarzeń jest pierwszy.
Krok 2: wyczyść stan offline zgłaszany przez stos HTTP
Klient pobiera profil i ocenia zasady przez komponenty HTTP systemu Windows, więc flaga trybu offline ustawiona w ustawieniach internetowych użytkownika może zepsuć inicjalizację, choć każda przeglądarka nadal wczytuje strony. Sprawdź wartość bezpośrednio:
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline
Wartość 1 oznacza, że stos WinINet informuje wywołujących, iż komputer nie ma połączenia; ten stan zwykle ustawia pozycja menu Praca w trybie offline w programie Internet Explorer lub skrypt automatyzacji. Ustaw ją z powrotem na 0, wyloguj się i zaloguj ponownie, i ponów połączenie, zanim zmienisz cokolwiek innego.
Jeśli odziedziczyłeś ten komputer i nie potrafisz powiedzieć, dlaczego flaga została ustawiona, odnotuj to w zgłoszeniu. Coś innego na komputerze mogło ustawić ją celowo i wróci przy następnym logowaniu.
Krok 3: uwolnij adapter wirtualny od Hyper-V lub ICS
Dwie role systemu Windows mogą trzymać elementy potrzebne klientowi do utworzenia adaptera. Hyper-V jest pierwsza: gdy usługi przełącznika wirtualnego działają, utworzenie adaptera może się nie udać w sposób, który objawia się tym błędem. Zatrzymanie usług jest diagnozą, nie poprawką:
Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"
Jeśli klient łączy się przy zatrzymanych usługach, konflikt jest potwierdzony i wiesz już, o czym rozmawiać z właścicielem hosta Hyper-V. Uruchom je ponownie później, chyba że komputer nie potrzebuje już wirtualizacji.
Udostępnianie połączenia internetowego to drugi właściciel. Jeśli jakieś połączenie jest udostępniane, klient może zawieść, zanim w ogóle utworzy tunel. Potwierdź za pomocą Get-Service SharedAccess i, jeśli działa i jest ustawione na automatycznie, przejrzyj adaptery w poszukiwaniu udostępnionego połączenia i wyłącz udostępnianie tylko na tym adapterze.
Jest też tańsze wyjaśnienie, które trzeba wykluczyć najpierw. Komputer bez żadnego działającego dostępu do internetu często pokazuje ten komunikat zamiast błędu osiągalności, więc potwierdź, że Test-NetConnection do adresu bramy i do hosta publicznego kończą się powodzeniem, zanim obwinisz klienta.
Zweryfikuj, a potem wycofaj to, czego nie potrzebowałeś
Weryfikacja to nie zielona tarcza w zasobniku. Potwierdź, że adapter istnieje, ma adres i przepuszcza ruch: Get-NetAdapter -Name "Cisco AnyConnect*" powinno pokazać go jako aktywnego, ipconfig /all powinno pokazać przypisany adres i serwery DNS, a rzeczywiste żądanie do nazwy wewnętrznej powinno być rozwiązywane przez tunel, a nie przez lokalny resolver.
Prowadź krótką listę każdej zmiany, z wartością, którą znalazłeś, i wartością, którą ustawiłeś. Jeśli połączenie działa po trzecim kroku, przywróć usługi Hyper-V i przetestuj ponownie przed zamknięciem zgłoszenia, bo obejście, które po cichu wyłącza wirtualizację, zostanie cofnięte przez następnego administratora, który to zauważy.
Jeśli żaden z trzech kroków nie rusza błędu, przestań zmieniać punkt końcowy. Zbierz wersję klienta, stan usługi, czas z góry tej strony i pakiet diagnostyczny, który klient może wytworzyć, a następnie przekaż je z dokładną kolejnością, której próbowałeś. Ten pakiet jest dla następnego inżyniera wart więcej niż zrzut ekranu okna i jest jedynym artefaktem, który pokazuje, czy podsystem zawiódł przed dotknięciem sieci, czy po nim.