¿Una máquina virtual de Hyper-V usa la VPN del host? Depende del conmutador

Instale un cliente VPN en el host de Hyper-V, abra allí un navegador y la dirección de salida cambia; abra la misma página dentro de la máquina virtual y puede mostrar la dirección antigua, o nada en absoluto. La conclusión habitual es que la máquina virtual está rota, o que hay que activar el túnel dividido. Ninguna de las dos se deduce. Un cliente VPN no es una propiedad de la máquina; es un conjunto de rutas, un adaptador virtual y a menudo un filtro ligado a interfaces concretas. Que el tráfico de los invitados llegue alguna vez a esa maquinaria depende del conmutador virtual que use el invitado.

El mito, dicho sin rodeos

La creencia es que una VPN instalada en el host protege toda la máquina, incluidas las máquinas virtuales, porque una máquina virtual no es más que un proceso que se ejecuta en esa máquina. Es una creencia cómoda, porque el antivirus y los cortafuegos del host suelen comportarse así. Las rutas de red no.

La trama de un invitado solo la toca la pila VPN del host si el host la enruta o la filtra. Copie esa frase en una nota adhesiva, porque cada caso de abajo es una variación de ella.

Tres tipos de conmutador, tres caminos

Un conmutador externo vincula un adaptador virtual a una tarjeta de red física, y el invitado envía tramas por ese vínculo con su propia dirección MAC. El invitado pasa a ser un par en la red física, con su propia concesión DHCP, su puerta de enlace y sus servidores DNS. La ruta predeterminada de la VPN del host vive en la pila del host y no mueve esas tramas, porque se puentean en lugar de enrutarse por el host. Por eso también un conmutador externo sobre un adaptador Wi-Fi es mala idea: la mayoría de los controladores inalámbricos no transportan tramas para una segunda dirección MAC.

Un conmutador interno conecta a los invitados con un adaptador virtual del host. Por sí solo no ofrece salida a internet; un objeto NAT en el host aporta la traducción, como se describe en la guía de NAT de Hyper-V. Ahora los paquetes del invitado sí entran en el enrutamiento y la ruta NAT del host, así que las rutas y los filtros del cliente VPN vuelven a importar. Esta es la disposición en la que la máquina virtual sigue de verdad la VPN del host, y en la que un kill switch puede cortar al invitado por completo.

Un conmutador privado no tiene adaptador de host ni enlace ascendente. Los invitados hablan entre sí y con nada más, así que si una máquina virtual en un conmutador privado no tiene internet, el enrutador que falta es la causa y la VPN es irrelevante.

El conmutador predeterminado es un arreglo propio

Windows incluye un conmutador predeterminado que combina un conmutador interno con NAT y un proxy DNS. Su subred la elige el host, puede cambiar tras reiniciar y no es el mismo objeto que una red NAT que usted cree. Reconstruirlo como si fuera una red de laboratorio es como la gente acaba con dos NAT y un invitado que sigue sin ruta.

Si la máquina virtual está en el conmutador predeterminado, lea la dirección que recibió el invitado y compárela con la tabla NAT del host antes de tocar el cliente VPN. Una discrepancia entre la puerta de enlace del invitado y el prefijo NAT explica más fallos que cualquier ajuste del cliente.

Cuatro hechos que resuelven la pregunta

Reúna esto antes de cambiar nada: el tipo de conmutador y su enlace ascendente, el adaptador conectado a la máquina virtual, la dirección, la puerta de enlace y el DNS del propio invitado, y el estado de NAT y de la ruta predeterminada del host. Los comandos de solo lectura son Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, y Get-NetRoute -DestinationPrefix 0.0.0.0/0; y dentro del invitado, ipconfig /all da el resto.

Luego decida qué debe hacer el invitado. Si debe quedarse fuera de la VPN, obtenga la excepción admitida por el proveedor para esa ruta exacta, porque excluir un ejecutable del host no exime el tráfico reenviado de la máquina virtual. Si debe usar la VPN, confirme el tratamiento documentado del cliente para el tráfico de máquinas virtuales en lugar de suponer que una prueba en el navegador del host lo cubre.

Una prueba dentro del invitado es la única evidencia que cuenta. Compruebe la dirección de salida desde el invitado, resuelva un nombre interno, vuelva a conectar la VPN y repita. El resultado del navegador del host no sustituye nada de eso.

Qué cuesta el mito

La gente desactiva el kill switch, añade rutas estáticas o borra y recrea conmutadores solo para que pase una prueba. Cada atajo cambia el modo de fallo: el invitado puede llegar a internet por un camino que nadie pretendía, o el host puede perder la conectividad cuando un conmutador externo vuelve a vincular su tarjeta física.

Volver a vincular un conmutador externo interrumpe el acceso del propio host, así que mantenga abierto un camino fuera de banda y evite borrar conmutadores mientras aún diagnostica. El resultado correcto es el camino deseado del invitado, incluido cómo se reconecta y cómo falla, no una marca verde de una carga de página.

La respuesta duradera es una línea por máquina virtual en el inventario: qué conmutador usa y qué componente le da su puerta de enlace. Con eso escrito, el próximo cambio de VPN es una consulta en lugar de una tarde de conjeturas.