¿Unha máquina virtual de Hyper-V usa a VPN do host? Depende do conmutador

Instale un cliente VPN no host de Hyper-V, abra alí un navegador e o enderezo de saída cambia; abra a mesma páxina dentro da máquina virtual e pode mostrar o enderezo antigo, ou nada de nada. A conclusión habitual é que a máquina virtual está avariada, ou que hai que activar o túnel dividido. Ningunha das dúas se deduce. Un cliente VPN non é unha propiedade da máquina; é un conxunto de rutas, un adaptador virtual e a miúdo un filtro ligado a interfaces concretas. Que o tráfico dos convidados chegue algunha vez a esa maquinaria depende do conmutador virtual que use o convidado.

O mito, dito sen rodeos

A crenza é que unha VPN instalada no host protexe toda a máquina, máquinas virtuais incluídas, porque unha máquina virtual non é máis que un proceso que se executa nesa máquina. É unha crenza cómoda, porque o antivirus e as devasas do host adoitan comportarse así. As rutas de rede non.

A trama dun convidado só a toca a pila VPN do host se o host a encamiña ou a filtra. Copie esa frase nunha nota adhesiva, porque cada caso de abaixo é unha variación dela.

Tres tipos de conmutador, tres camiños

Un conmutador externo vincula un adaptador virtual a unha tarxeta de rede física, e o convidado envía tramas por ese vínculo coa súa propia dirección MAC. O convidado pasa a ser un par na rede física, coa súa propia concesión DHCP, a súa porta de enlace e os seus servidores DNS. A ruta predeterminada da VPN do host vive na pila do host e non move esas tramas, porque se pontean en lugar de encamiñarse polo host. Por iso tamén un conmutador externo sobre un adaptador Wi-Fi é mala idea: a maioría dos controladores sen fíos non transportan tramas para unha segunda dirección MAC.

Un conmutador interno conecta os convidados cun adaptador virtual do host. Por si só non ofrece saída a internet; un obxecto NAT no host achega a tradución, como se describe na guía de NAT de Hyper-V. Agora os paquetes do convidado si entran no encamiñamento e no camiño NAT do host, así que as rutas e os filtros do cliente VPN volven importar. Esta é a disposición na que a máquina virtual segue de verdade a VPN do host, e na que un kill switch pode cortar o convidado por completo.

Un conmutador privado non ten adaptador de host nin enlace ascendente. Os convidados falan entre si e con nada máis, así que se unha máquina virtual nun conmutador privado non ten internet, o encamiñador que falta é a causa e a VPN é irrelevante.

O conmutador predeterminado é un arranxo propio

Windows inclúe un conmutador predeterminado que combina un conmutador interno con NAT e un proxy DNS. A súa subrede elíxea o host, pode cambiar tras reiniciar e non é o mesmo obxecto que unha rede NAT que vostede cree. Reconstruílo como se fose unha rede de laboratorio é como a xente acaba con dous NAT e un convidado que segue sen ruta.

Se a máquina virtual está no conmutador predeterminado, lea o enderezo que recibiu o convidado e compárao coa táboa NAT do host antes de tocar o cliente VPN. Unha discrepancia entre a porta de enlace do convidado e o prefixo NAT explica máis fallos que calquera axuste do cliente.

Catro feitos que resolven a pregunta

Reúna isto antes de cambiar nada: o tipo de conmutador e o seu enlace ascendente, o adaptador conectado á máquina virtual, o enderezo, a porta de enlace e o DNS do propio convidado, e o estado de NAT e da ruta predeterminada do host. Os comandos de só lectura son 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.

Despois decida que debe facer o convidado. Se debe quedar fóra da VPN, obteña a excepción admitida polo provedor para esa ruta exacta, porque excluír un executable do host non exime o tráfico reenviado da máquina virtual. Se debe usar a VPN, confirme o tratamento documentado do cliente para o tráfico de máquinas virtuais en lugar de supoñer que unha proba no navegador do host o cobre.

Unha proba dentro do convidado é a única evidencia que conta. Comprobe o enderezo de saída desde o convidado, resolva un nome interno, volva conectar a VPN e repita. O resultado do navegador do host non substitúe nada diso.

Que custa o mito

A xente desactiva o kill switch, engade rutas estáticas ou borra e recrea conmutadores só para que pase unha proba. Cada atallo cambia o modo de fallo: o convidado pode chegar a internet por un camiño que ninguén pretendía, ou o host pode perder a conectividade cando un conmutador externo volve vincular a súa tarxeta física.

Volver vincular un conmutador externo interrompe o acceso do propio host, así que manteña aberto un camiño fóra de banda e evite borrar conmutadores mentres aínda diagnostica. O resultado correcto é o camiño desexado do convidado, incluído como se reconecta e como falla, non unha marca verde dunha carga de páxina.

A resposta duradeira é unha liña por máquina virtual no inventario: que conmutador usa e que compoñente lle dá a súa porta de enlace. Con isto escrito, o próximo cambio de VPN é unha consulta en lugar dunha tarde de conxecturas.