Cisco VPN colga tras Hyper-V: ¿desvincular ou reconstruír?

O cliente xira en securing communications e nunca mostra unha solicitude de inicio de sesión, e o único que cambiou foi unha instalación de emulador. Ese patrón apunta ao adaptador virtual, non ao perfil nin ao contrasinal. A decisión é se o adaptador está vinculado a un conmutador Hyper-V no que non debería estar, ou se nunca se levantou.

Eses dous estados parécense no cliente e necesitan reparacións distintas. Un é unha vinculación que pode desfacer; o outro é un problema de controlador que desvincular non tocará.

Que espera a etapa securing communications

Antes de construír o túnel, o cliente necesita unha ruta de rede local operativa cara á pasarela. Instala o seu propio adaptador virtual e úsao como parte desa ruta. Se Hyper-V conecta ese adaptador a un conmutador creado para un emulador, o adaptador pode deixar de ofrecer unha ruta utilizábel.

O cliente non informa de que adaptador está esperando. O rexistro adoita rematar na última etapa acadada, e o mesmo fallo aparece para cada enderezo de pasarela. Por iso o historial de instalación importa máis que o texto do erro. O rexistro segue merecendo a pena; dille a etapa, non a causa.

Volver introducir as credenciais ou reinstalar o perfil non pode cambiar unha vinculación de conmutador. Se eses son os seus dous primeiros movementos, está reparando a capa incorrecta.

Decisión unha: está o adaptador VPN vinculado ao conmutador incorrecto?

Abra Hyper-V Manager, logo Virtual Switch Manager, e lea a lista de adaptadores de cada conmutador. O adaptador Cisco non debería aparecer como conexión dun conmutador de emulador. Se aparece, é culpa súa, e a reparación é quitarlle ese conmutador.

Reinicie primeiro para que o cliente arrinque limpo e non medio conectado. Quite a vinculación, aplíquea e deixe os demais adaptadores en paz ata que probase. O cambio é reversible e non desinstala nada, pero anote que adaptadores desvinculou.

Inicie o cliente e probe a conexión. Se segue atascado, desvincule os adaptadores virtuais restantes un a un e probe despois de cada un, para saber cal importaba.

Decisión dúas: está o adaptador activo pero sen enderezo?

Execute ipconfig /all desde unha consola elevada para que se inclúan os adaptadores ocultos, e compare a lista co que recorde de antes da instalación. Un adaptador sen enderezo e con estado de medio desconectado adoita significar que o controlador non se iniciou. Iso non se repara desvinculando. Anote o estado exacto antes de cambiar nada.

Un adaptador que está activo pero conectado ao conmutador incorrecto é o caso da sección anterior. O estado do enderezo é como distingue os dous.

Restaura o emulador sen restaurar o fallo

Cando o túnel funcione, volva conectar o adaptador propio do emulador ao seu conmutador e confirme que a VM obtén un enderezo. Non volva conectar o adaptador VPN. Probe tanto o emulador como o cliente unha vez máis antes de dalo por terminado.

Nunha estación de traballo xestionada, diga ao administrador que vinculación cambiou. Unha actualización de políticas posterior pode restaurar a conexión anterior, e o colgado volverá sen causa evidente.

Anote o nome do adaptador, o conmutador ao que estaba vinculado e o estado de ipconfig antes e despois. Se o colgado volve tras unha actualización, ese rexistro é a diferenza entre unha comprobación de cinco minutos e comezar de cero.