Cisco VPN trava após o Hyper-V: desvincular ou reconstruir?

O cliente gira em securing communications e nunca mostra um pedido de início de sessão, e a única coisa que mudou foi uma instalação de emulador. Esse padrão aponta para o adaptador virtual, não para o perfil ou a palavra-passe. A decisão é se o adaptador está vinculado a um comutador Hyper-V onde não deveria estar, ou se nunca apareceu.

Esses dois estados parecem iguais no cliente e exigem reparações diferentes. Um é uma vinculação que pode desfazer; o outro é um problema de controlador que desvincular não vai tocar.

O que a fase securing communications espera

Antes de o túnel ser construído, o cliente precisa de um caminho de rede local funcional até o gateway. Instala o seu próprio adaptador virtual e usa-o como parte desse caminho. Se o Hyper-V ligar esse adaptador a um comutador criado para um emulador, o adaptador pode deixar de oferecer uma rota utilizável.

O cliente não informa de que adaptador está à espera. O registo costuma terminar na última fase alcançada, e a mesma falha aparece para cada endereço de gateway. Por isso o histórico de instalação importa mais do que o texto do erro. O registo ainda vale a pena guardar; diz a fase, não a causa.

Voltar a introduzir as credenciais ou reinstalar o perfil não pode alterar uma vinculação de comutador. Se esses são os seus dois primeiros passos, está a reparar a camada errada.

Decisão um: o adaptador VPN está vinculado ao comutador errado?

Abra o Hyper-V Manager, depois o Virtual Switch Manager, e leia a lista de adaptadores de cada comutador. O adaptador Cisco não deve aparecer como ligação de um comutador de emulador. Se aparecer, é culpa sua, e a reparação é removê-lo desse comutador.

Reinicie primeiro para que o cliente arranque limpo e não meio ligado. Remova a vinculação, aplique-a e deixe os outros adaptadores em paz até ter testado. A alteração é reversível e não desinstala nada, mas anote que adaptadores desvinculou.

Inicie o cliente e tente a ligação. Se continuar a travar, desvincule os restantes adaptadores virtuais um de cada vez e teste após cada um, para saber qual importava.

Decisão dois: o adaptador está ativo mas sem endereço?

Execute ipconfig /all a partir de uma linha de comandos elevada para que os adaptadores ocultos sejam incluídos, e compare a lista com o que se lembra de antes da instalação. Um adaptador sem endereço e com estado de suporte desligado costuma significar que o controlador não iniciou. Isso não se repara desvinculando. Anote o estado exato antes de alterar qualquer coisa.

Um adaptador ativo mas ligado ao comutador errado é o caso da secção anterior. O estado do endereço é o que distingue os dois.

Restaure o emulador sem restaurar a falha

Quando o túnel funcionar, volte a ligar o adaptador próprio do emulador ao seu comutador e confirme que a VM obtém um endereço. Não volte a ligar o adaptador VPN. Teste tanto o emulador como o cliente mais uma vez antes de considerar terminado.

Num posto de trabalho gerido, diga ao administrador que vinculação alterou. Uma atualização de políticas posterior pode restaurar a ligação antiga, e o bloqueio regressa sem causa evidente.

Anote o nome do adaptador, o comutador a que estava vinculado e o estado de ipconfig antes e depois. Se o bloqueio voltar após uma atualização, esse registo é a diferença entre uma verificação de cinco minutos e começar de novo.