Uma VM do Hyper-V usa a VPN do host? Depende do comutador

Instale um cliente VPN no host do Hyper-V, abra um navegador lá, e o endereço de saída muda; abra a mesma página dentro da máquina virtual e ela pode mostrar o endereço antigo, ou nada. A conclusão habitual é que a máquina virtual está avariada, ou que o túnel dividido precisa ser ativado. Nenhuma das duas se segue. Um cliente VPN não é uma propriedade da máquina; é um conjunto de rotas, um adaptador virtual e muitas vezes um filtro ligado a interfaces específicas. Se o tráfego dos convidados alguma vez encontra essa maquinaria depende do comutador virtual que o convidado usa.

O mito, dito sem rodeios

A crença é que uma VPN instalada no host protege a máquina inteira, incluindo as máquinas virtuais, porque uma máquina virtual é apenas um processo em execução nessa máquina. É uma crença confortável, porque o antivírus e as firewalls do host costumam comportar-se assim. Os caminhos de rede não.

O frame de um convidado só é tocado pela pilha VPN do host se o host o encaminhar ou filtrar. Copie essa frase para um papel autocolante, porque cada caso abaixo é uma variante dela.

Três tipos de comutador, três caminhos

Um comutador externo liga um adaptador virtual a uma placa de rede física, e o convidado envia frames por essa ligação com o seu próprio endereço MAC. O convidado torna-se um par na rede física, com a sua própria concessão DHCP, gateway e servidores DNS. A rota predefinida da VPN do host vive na pilha do host e não move esses frames, porque são pontados em vez de encaminhados pelo host. É também por isso que um comutador externo sobre um adaptador Wi-Fi é má ideia: a maioria dos controladores sem fios não transporta frames para um segundo endereço MAC.

Um comutador interno liga os convidados a um adaptador virtual do host. Por si só não oferece saída para a internet; um objeto NAT no host fornece a tradução, como descrito no guia NAT do Hyper-V. Agora os pacotes do convidado entram realmente no encaminhamento e no caminho NAT do host, por isso as rotas e os filtros do cliente VPN voltam a contar. Esta é a disposição em que a máquina virtual segue realmente a VPN do host, e em que um kill switch pode cortar o convidado por completo.

Um comutador privado não tem adaptador de host nem ligação ascendente. Os convidados falam entre si e com mais nada, por isso, se uma máquina virtual num comutador privado não tem internet, o router em falta é a causa e a VPN é irrelevante.

O comutador predefinido é uma disposição própria

O Windows inclui um comutador predefinido que combina um comutador interno com NAT e um proxy DNS. A sua sub-rede é escolhida pelo host, pode mudar após reinícios e não é o mesmo objeto que uma rede NAT que você cria. Reconstruí-lo como se fosse uma rede de laboratório é como as pessoas acabam com duas NAT e um convidado ainda sem rota.

Se a máquina virtual está no comutador predefinido, leia o endereço que o convidado recebeu e compare-o com a tabela NAT do host antes de tocar no cliente VPN. Uma discrepância entre o gateway do convidado e o prefixo NAT explica mais falhas do que qualquer ajuste do cliente.

Quatro factos que resolvem a questão

Reúna isto antes de mudar qualquer coisa: o tipo de comutador e a sua ligação ascendente, o adaptador ligado à máquina virtual, o endereço, o gateway e o DNS do próprio convidado, e o estado de NAT e da rota predefinida do host. Os comandos só de leitura são Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, e Get-NetRoute -DestinationPrefix 0.0.0.0/0; e dentro do convidado, ipconfig /all dá o resto.

Depois decida o que o convidado deve fazer. Se deve ficar fora da VPN, obtenha a exceção suportada pelo fornecedor para esse caminho exato, porque excluir um executável do host não isenta o tráfego reencaminhado da máquina virtual. Se deve usar a VPN, confirme o tratamento documentado do cliente para o tráfego de máquinas virtuais em vez de assumir que um teste no navegador do host o cobre.

Um teste dentro do convidado é a única evidência que conta. Verifique o endereço de saída a partir do convidado, resolva um nome interno, reconecte a VPN e repita. O resultado do navegador do host não substitui nada disso.

O que custa o mito

As pessoas desativam o kill switch, adicionam rotas estáticas ou apagam e recriam comutadores só para fazer passar um teste. Cada atalho muda o modo de falha: o convidado pode chegar à internet por um caminho que ninguém pretendia, ou o host pode perder a conectividade quando um comutador externo volta a ligar a sua placa física.

Voltar a ligar um comutador externo interrompe o acesso do próprio host, por isso mantenha um caminho fora de banda aberto e evite apagar comutadores enquanto ainda está a diagnosticar. O resultado correto é o caminho pretendido do convidado, incluindo como se reconecta e como falha, não um visto verde de um carregamento de página.

A resposta duradoura é uma linha por máquina virtual no inventário: que comutador usa e que componente fornece o seu gateway. Com isso escrito, a próxima mudança de VPN é uma consulta em vez de uma tarde de suposições.