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 до и после. Если зависание вернётся после обновления, эта запись — разница между пятиминутной проверкой и началом с нуля.