El invitado de Hyper-V pierde DNS cuando se conecta la VPN del host

El invitado estaba bien esta mañana. Luego el host levantó Cisco AnyConnect y la VM perdió DNS, la confianza del dominio y la carpeta compartida, sin que nada cambiara dentro de ella. Un túnel de host y una red de invitado son rutas separadas, y conectar una no mueve la otra. Trabaje desde dentro del invitado hacia fuera y anote lo que ve antes de cambiar nada.

Qué puede ver todavía el invitado

Registre la dirección, la puerta de enlace predeterminada y el resolutor en la VM, una vez antes de que el host se conecte y otra después. Un invitado que conservó su dirección y solo perdió la resolución de nombres tiene un problema de resolutor. Un invitado que nunca tuvo ruta tiene un problema de ruta, y ambos requieren trabajos distintos. Desde el host no puede distinguirlos, por eso la lectura tiene que venir de dentro.

Esas tres lecturas, tomadas dos veces, son su línea base. Todo lo posterior se mide contra ellas.

Qué salida usa el invitado

Hyper-V responde a esto con dos comandos: Get-VMSwitch enumera los conmutadores, y Get-VMNetworkAdapter -VMName TestVM muestra aquel al que está conectado el invitado. El Default Switch es una red NAT que Windows administra; un conmutador externo entrega el tráfico a un adaptador físico; un conmutador interno no transporta nada hasta que alguien añade NAT o un enrutador. VirtualBox presenta las mismas tres ideas como NAT, NAT Network y bridged.

El modo decide si el túnel del host puede importar siquiera. Un invitado NAT lo traduce WinNAT y luego lo reenvía la pila del host, así que sigue la tabla de rutas del host; con un cliente de túnel completo su tráfico es el tráfico que entra en el adaptador VPN, y se descarta cuando el cliente bloquea la subred local. Un invitado puente sobre un conmutador externo nunca llega al enrutamiento del host: sus tramas salen directamente de la NIC física, así que evita tanto el túnel como la política de LAN local del cliente.

Compartir el túnel del host con Hyper-V

Si el invitado necesita el túnel y no puede ejecutar su propio cliente, Windows puede compartir la conexión VPN. Abra las propiedades del adaptador VPN, vaya a Compartir y permita que otros usuarios de red se conecten a través de él. Apunte la conexión de red doméstica al adaptador de Hyper-V, vEthernet (Default Switch), y luego pruebe una petición nueva desde dentro del invitado.

Trate esta disposición como una solución de laboratorio, porque se comporta como tal. Debe volver a aplicarse tras una desconexión, una reconexión o un reinicio del host. En algunas compilaciones de Windows 11 el adaptador falta por completo en el desplegable, y entonces esta ruta queda cerrada.

Reinstalar la característica Hyper-V ha rescatado a unos cuantos invitados testarudos. Déjelo para el final y anote primero el estado del invitado.

Reenvío de puertos cuando la subred está filtrada

Una VPN de host que filtra la subred NAT del invitado rompe el acceso directo, no la resolución de nombres. La VM se ejecuta, pero ssh [email protected] se cuelga, mientras la traducción del hipervisor sigue funcionando. Reenvíe los puertos que el trabajo necesita y conéctese a la dirección del host en su lugar. Las líneas de Vagrantfile de abajo cubren SSH y un servicio HTTPS; ambas se añaden antes de la recarga.

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

La resolución de nombres es una decisión aparte y merece su propia corrección. Active la característica de resolutor del host para ese adaptador NAT, o configure el servidor DNS interno dentro del invitado a mano. Apuntar el invitado a un resolutor público hace que la navegación funcione y rompe todos los nombres internos, lo cual es peor que la caída porque parece un éxito. Pruebe un nombre que solo conozca el resolutor interno.

La comprobación que le dice que funcionó

Después de cualquiera de estos cambios, ejecute una petición nueva desde dentro del invitado con la VPN del host conectada, no antes. Vuelva a comprobar el uso compartido tras una reconexión y tras un reinicio, porque una corrección que solo sobrevive a uno de los dos no es una corrección. Confirme que la lista de resolutores del invitado coincide con la red que su tráfico usa de verdad. Luego pruebe el reenvío de puertos desde la dirección del host, porque probarlo desde el invitado no demuestra nada. Desde dentro del invitado, dos comprobaciones de PowerShell cubren el resolutor y el puerto reenviado:

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

Registre cada cambio de conmutador o controlador con su paso de deshacer. La guía de Microsoft sobre Hyper-V NAT explica qué es realmente el Default Switch, y vale la pena leerla antes de crear una segunda red NAT que entre en conflicto con ella.