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 да і пасля. Калі завісанне вернецца пасля абнаўлення, гэты запіс — розніца паміж пяціхвіліннай праверкай і пачаткам з нуля.