Cisco VPN зависає після Hyper-V: зняти прив'язку чи перезібрати?

Клієнт крутиться на securing communications і ніколи не показує запит входу, а єдине, що змінилося, — встановлення емулятора. Така картина вказує на віртуальний адаптер, а не на профіль чи пароль. Рішення в тому, чи адаптер прив'язаний до комутатора Hyper-V, на якому його не повинно бути, чи він узагалі не піднявся.

Ці два стани виглядають у клієнті однаково й потребують різного ремонту. Одне — прив'язка, яку можна скасувати; інше — проблема драйвера, якої зняття прив'язки не торкнеться.

Чого чекає етап securing communications

Перш ніж буде збудовано тунель, клієнтові потрібен робочий локальний мережевий шлях до шлюзу. Він встановлює власний віртуальний адаптер і використовує його як частину цього шляху. Якщо Hyper-V підключить цей адаптер до комутатора, створеного для емулятора, адаптер може перестати давати придатний маршрут.

Клієнт не повідомляє, якого адаптера він чекає. Журнал зазвичай обривається на останньому досягнутому етапі, і та сама помилка з'являється для кожної адреси шлюзу. Тому історія встановлення важливіша за текст помилки. Журнал усе ж варто зберегти; він каже про етап, а не про причину.

Повторне введення облікових даних або перевстановлення профілю не можуть змінити прив'язку до комутатора. Якщо це ваші перші два кроки, ви ремонтуєте не той рівень.

Рішення перше: чи прив'язаний VPN-адаптер до неправильного комутатора?

Відкрийте Hyper-V Manager, потім Virtual Switch Manager і прочитайте список адаптерів для кожного комутатора. Адаптер Cisco не повинен відображатися як підключення комутатора емулятора. Якщо відображається, це ваша помилка, і ремонт — прибрати його з цього комутатора.

Спочатку перезавантажтеся, щоб клієнт стартував чисто, а не наполовину підключеним. Зніміть прив'язку, застосуйте її й не чіпайте інші адаптери, доки не перевірите. Зміна оборотна й нічого не видаляє, але запишіть, які адаптери ви відв'язали.

Запустіть клієнт і спробуйте підключення. Якщо він усе ще зависає, відв'язуйте решту віртуальних адаптерів по одному й перевіряйте після кожного, щоб знати, який мав значення.

Рішення друге: адаптер працює, але без адреси?

Виконайте ipconfig /all з командного рядка з підвищеними правами, щоб приховані адаптери теж потрапили до списку, і порівняйте список із тим, що пам'ятаєте до встановлення. Адаптер без адреси й зі станом від'єднаного носія зазвичай означає, що драйвер не запустився. Це не виправляється відв'язуванням. Запишіть точний стан, перш ніж щось змінювати.

Адаптер, який працює, але підключений до неправильного комутатора, — це випадок із попереднього розділу. Саме стан адреси дає змогу розрізнити ці два випадки.

Поверніть емулятор, не повертаючи несправність

Коли тунель запрацює, знову підключіть власний адаптер емулятора до його комутатора й переконайтеся, що VM отримує адресу. Не підключайте VPN-адаптер назад. Перевірте і емулятор, і клієнт ще раз, перш ніж вважати справу закритою.

На керованій робочій станції повідомте адміністратора, яку прив'язку ви змінили. Подальше оновлення політик може повернути старе підключення, і зависання повернеться без очевидної причини.

Запишіть ім'я адаптера, комутатор, до якого він був прив'язаний, і стан ipconfig до та після. Якщо зависання повернеться після оновлення, цей запис — різниця між п'ятихвилинною перевіркою та початком з нуля.