Cisco VPN zawiesza się po Hyper-V: odłączyć powiązanie czy zbudować od nowa?
Klient zatrzymuje się na securing communications po instalacji emulatora. Sprawdź, czy adapter VPN jest powiązany z niewłaściwym przełącznikiem Hyper-V, czy wcale nie wystartował.
Klient kręci się na securing communications i nigdy nie pokazuje monitu logowania, a jedyną zmianą była instalacja emulatora. Ten wzorzec wskazuje na adapter wirtualny, nie na profil ani hasło. Decyzja dotyczy tego, czy adapter jest powiązany z przełącznikiem Hyper-V, na którym nie powinien być, czy w ogóle się nie pojawił.
Te dwa stany wyglądają w kliencie tak samo i wymagają innych napraw. Jeden to powiązanie, które można cofnąć; drugi to problem sterownika, którego odłączenie powiązania nie dotknie.
Na co czeka etap securing communications
Zanim tunel zostanie zbudowany, klient potrzebuje działającej lokalnej ścieżki sieciowej do bramy. Instaluje własny adapter wirtualny i używa go jako części tej ścieżki. Jeśli Hyper-V podłączy ten adapter do przełącznika utworzonego dla emulatora, adapter może przestać oferować użyteczną trasę.
Klient nie zgłasza, na który adapter czeka. Dziennik zwykle kończy się na ostatnim osiągniętym etapie, a ten sam błąd pojawia się dla każdego adresu bramy. Dlatego historia instalacji jest ważniejsza niż tekst błędu. Dziennik wciąż warto zachować; mówi etap, nie przyczynę.
Ponowne wpisanie poświadczeń lub przeinstalowanie profilu nie może zmienić powiązania z przełącznikiem. Jeśli to twoje pierwsze dwa kroki, naprawiasz niewłaściwą warstwę.
Decyzja pierwsza: czy adapter VPN jest powiązany z niewłaściwym przełącznikiem?
Otwórz Hyper-V Manager, potem Virtual Switch Manager, i przeczytaj listę adapterów dla każdego przełącznika. Adapter Cisco nie powinien pojawiać się jako podłączenie przełącznika emulatora. Jeśli się pojawia, to twój błąd, a naprawą jest usunięcie go z tego przełącznika.
Najpierw uruchom ponownie, aby klient wystartował czysto, a nie w połowie podłączony. Usuń powiązanie, zastosuj je i zostaw inne adaptery w spokoju, dopóki nie przetestujesz. Zmiana jest odwracalna i niczego nie odinstalowuje, ale zapisz, które adaptery odłączyłeś.
Uruchom klienta i spróbuj połączenia. Jeśli nadal się zawiesza, odłączaj pozostałe adaptery wirtualne po jednym i testuj po każdym, aby wiedzieć, który miał znaczenie.
Decyzja druga: czy adapter działa, ale nie ma adresu?
Uruchom ipconfig /all z podniesionego wiersza poleceń, aby uwzględnić ukryte adaptery, i porównaj listę z tym, co pamiętasz sprzed instalacji. Adapter bez adresu i ze stanem odłączonego nośnika zwykle oznacza, że sterownik nie wystartował. Tego nie naprawia odłączenie powiązania. Zanotuj dokładny stan, zanim cokolwiek zmienisz.
Adapter, który działa, ale jest podłączony do niewłaściwego przełącznika, to przypadek z poprzedniej sekcji. Stan adresu jest tym, co odróżnia oba.
Przywróć emulator bez przywracania usterki
Gdy tunel działa, podłącz ponownie własny adapter emulatora do jego przełącznika i potwierdź, że VM dostaje adres. Nie podłączaj ponownie adaptera VPN. Przetestuj jeszcze raz zarówno emulator, jak i klienta, zanim uznasz to za zakończone.
Na zarządzanej stacji roboczej powiedz administratorowi, które powiązanie zmieniłeś. Późniejsze odświeżenie zasad może przywrócić stare podłączenie, a zawieszenie wróci bez wyraźnej przyczyny.
Zapisz nazwę adaptera, przełącznik, z którym był powiązany, oraz stan ipconfig przed i po. Jeśli zawieszenie wróci po aktualizacji, ten zapis jest różnicą między pięciominutową kontrolą a zaczynaniem od zera.