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 преди и след. Ако забиването се върне след актуализация, този запис е разликата между петминутна проверка и започване отначало.