O convidado do Hyper-V perde DNS quando a VPN do host se conecta

O convidado estava bem esta manhã. Então o host iniciou o Cisco AnyConnect e a VM perdeu o DNS, a confiança do domínio e a pasta compartilhada, sem que nada mudasse dentro dela. Um túnel de host e uma rede de convidado são caminhos separados, e conectar um não move o outro. Trabalhe de dentro do convidado para fora e anote o que vê antes de mudar qualquer coisa.

O que o convidado ainda consegue ver

Registre o endereço, o gateway padrão e o resolvedor na VM, uma vez antes de o host se conectar e uma vez depois. Um convidado que manteve o endereço e perdeu apenas a resolução de nomes tem um problema de resolvedor. Um convidado que nunca teve rota tem um problema de caminho, e os dois exigem trabalhos diferentes. Do host não é possível distingui-los, por isso a leitura precisa vir de dentro.

Essas três leituras, feitas duas vezes, são sua linha de base. Tudo depois é medido contra elas.

Qual saída o convidado usa

O Hyper-V responde a isso com dois comandos: Get-VMSwitch lista os switches, e Get-VMNetworkAdapter -VMName TestVM mostra aquele ao qual o convidado está conectado. O Default Switch é uma rede NAT gerenciada pelo Windows; um switch externo entrega o tráfego a um adaptador físico; um switch interno não transporta nada até alguém adicionar NAT ou um roteador. O VirtualBox apresenta as mesmas três ideias como NAT, NAT Network e bridged.

O modo decide se o túnel do host pode importar. Um convidado NAT é traduzido pelo WinNAT e depois encaminhado pela pilha do host, então segue a tabela de rotas do host; com um cliente de túnel completo, seu tráfego é o tráfego que entra no adaptador VPN, e é descartado quando o cliente bloqueia a sub-rede local. Um convidado em bridge num switch externo nunca chega ao roteamento do host: seus quadros saem diretamente da NIC física, então contorna tanto o túnel quanto a política de LAN local do cliente.

Compartilhar o túnel do host com o Hyper-V

Se o convidado precisa do túnel e não consegue executar seu próprio cliente, o Windows pode compartilhar a conexão VPN. Abra as propriedades do adaptador VPN, vá para Compartilhamento e permita que outros usuários de rede se conectem por ele. Aponte a conexão de rede doméstica para o adaptador do Hyper-V, vEthernet (Default Switch), e então teste uma nova solicitação de dentro do convidado.

Trate esta configuração como uma solução de laboratório, porque ela se comporta assim. Ela precisa ser reaplicada após uma desconexão, uma reconexão ou uma reinicialização do host. Em algumas compilações do Windows 11 o adaptador falta totalmente na lista suspensa, e então esse caminho fica fechado.

Reinstalar o recurso Hyper-V já salvou alguns convidados teimosos. Deixe isso para o fim e anote primeiro o estado do convidado.

Encaminhamento de portas quando a sub-rede é filtrada

Uma VPN de host que filtra a sub-rede NAT do convidado quebra o acesso direto, não a resolução de nomes. A VM está em execução, mas ssh [email protected] trava, enquanto a tradução do hipervisor ainda funciona. Encaminhe as portas de que o trabalho precisa e conecte-se ao endereço do host em vez disso. As linhas do Vagrantfile abaixo cobrem SSH e um serviço HTTPS; ambas entram antes da recarga.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

A resolução de nomes é uma decisão separada e merece sua própria correção. Ative o recurso de resolvedor do host para esse adaptador NAT, ou configure o servidor DNS interno dentro do convidado manualmente. Apontar o convidado para um resolvedor público faz a navegação funcionar e quebra todos os nomes internos, o que é pior do que a queda porque parece sucesso. Teste um nome que só o resolvedor interno conhece.

A verificação que diz que funcionou

Depois de qualquer uma dessas mudanças, execute uma nova solicitação de dentro do convidado com a VPN do host conectada, não antes. Verifique novamente o compartilhamento após uma reconexão e após uma reinicialização, porque uma correção que sobrevive apenas a uma das duas não é correção. Confirme que a lista de resolvedores do convidado corresponde à rede que seu tráfego realmente usa. Depois teste o encaminhamento de portas a partir do endereço do host, porque testá-lo a partir do convidado não prova nada. De dentro do convidado, duas verificações do PowerShell cobrem o resolvedor e a porta encaminhada:

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

Anote cada mudança de switch ou driver com seu passo de desfazer. O guia da Microsoft sobre Hyper-V NAT explica o que o Default Switch realmente é, e vale a pena lê-lo antes de criar uma segunda rede NAT que entre em conflito com ele.