Cisco VPN es penja després de Hyper-V: desvincular o reconstruir?

El client gira a securing communications i no mostra mai l'indicador d'inici de sessió, i l'única cosa que va canviar va ser una instal·lació d'emulador. Aquest patró apunta a l'adaptador virtual, no al perfil ni a la contrasenya. La decisió és si l'adaptador està vinculat a un commutador Hyper-V on no hauria de ser, o si no s'ha aixecat gens.

Aquests dos estats semblen iguals al client i necessiten reparacions diferents. Un és una vinculació que podeu desfer; l'altre és un problema de controlador que desvincular no tocarà.

Què espera l'etapa securing communications

Abans de construir el túnel, el client necessita un camí de xarxa local operatiu fins a la passarel·la. Instal·la el seu propi adaptador virtual i l'utilitza com a part d'aquest camí. Si Hyper-V connecta aquest adaptador a un commutador creat per a un emulador, l'adaptador pot deixar de presentar una ruta utilitzable.

El client no informa de quin adaptador espera. El registre sol acabar a l'última etapa a què va arribar, i la mateixa fallada apareix per a cada adreça de passarel·la. Per això l'historial d'instal·lació importa més que el text de l'error. El registre encara val la pena conservar-lo; us diu l'etapa, no la causa.

Tornar a introduir les credencials o reinstal·lar el perfil no pot canviar una vinculació de commutador. Si aquests són els vostres dos primers moviments, esteu reparant la capa equivocada.

Decisió primera: l'adaptador VPN està vinculat al commutador equivocat?

Obriu Hyper-V Manager, després Virtual Switch Manager, i llegiu la llista d'adaptadors de cada commutador. L'adaptador Cisco no hauria d'aparèixer com a connexió d'un commutador d'emulador. Si hi apareix, és error vostre, i la reparació és treure'l d'aquell commutador.

Reinicieu primer perquè el client arrenqui net i no mig connectat. Traieu la vinculació, apliqueu-la i deixeu els altres adaptadors en pau fins que hàgiu provat. El canvi és reversible i no desinstal·la res, però anoteu quins adaptadors heu desvinculat.

Inicieu el client i proveu la connexió. Si encara s'atura, desvinculeu els adaptadors virtuals restants d'un en un i proveu després de cada un, per saber quin era el que importava.

Decisió segona: l'adaptador funciona però no té adreça?

Executeu ipconfig /all des d'un indicador elevat perquè s'incloguin els adaptadors ocults, i compareu la llista amb el que recordeu d'abans de la instal·lació. Un adaptador sense adreça i amb estat de mitjà desconnectat sol significar que el controlador no s'ha iniciat. Això no es repara desvinculant. Anoteu l'estat exacte abans de canviar res.

Un adaptador que funciona però està connectat al commutador equivocat és el cas de la secció anterior. L'estat de l'adreça és com distingiu els dos casos.

Restaureu l'emulador sense restaurar la fallada

Quan el túnel funcioni, torneu a connectar l'adaptador propi de l'emulador al seu commutador i confirmeu que la VM obté una adreça. No torneu a connectar l'adaptador VPN. Proveu tant l'emulador com el client una vegada més abans de donar-ho per acabat.

En una estació de treball gestionada, digueu a l'administrador quina vinculació heu canviat. Una actualització de polítiques posterior pot restaurar l'antiga connexió, i el penjament tornarà sense cap causa òbvia.

Anoteu el nom de l'adaptador, el commutador al qual estava vinculat i l'estat de ipconfig abans i després. Si el penjament torna després d'una actualització, aquest registre és la diferència entre una comprovació de cinc minuts i començar de zero.