Su máquina virtual no alcanza un sistema interno que funciona perfectamente en el anfitrión, y el anfitrión está conectado mediante un cliente que posee la tabla de enrutamiento. Puentear el adaptador virtual al túnel parece obvio y falla por dos razones separadas. Lo que funciona es la traducción en un segmento que ambas máquinas poseen. El costo es real: cada invitado deja de tener identidad propia en la red corporativa.

Dos razones por las que el puente no puede funcionar

El adaptador del cliente suele llevar una sola dirección, a menudo /32, y el cliente reescribe las rutas del anfitrión para que el tráfico saliente ordinario prefiera el túnel. Las aplicaciones del anfitrión obedecen esa tabla y llegan al sistema privado. Un invitado puenteado nunca lee la tabla, porque sus tramas salen por un conmutador por debajo de la capa IP.

Poner el adaptador de túnel dentro de un puente resolvería la ruta en teoría, y el controlador no lo aceptará. Windows 10 también permite un solo dispositivo de puente y retiene el rol de enrutamiento que dejaría a una estación de trabajo reenviar entre dos subredes. Lo que queda es la traducción de origen. Haga que el tráfico del invitado parezca venir del anfitrión, y las decisiones del propio anfitrión lo llevan al túnel sin que el invitado necesite una ruta que no puede tener.

Cree un segmento que posea el anfitrión

En el editor de red virtual, agregue una red solo de anfitrión como VMnet3 en un prefijo que no enrute en ningún otro sitio, por ejemplo 172.28.90.0/24. El anfitrión toma 172.28.90.1 en ese adaptador y el invitado se conecta al mismo conmutador. Desactive el DHCP del hipervisor en ese segmento para que lo posea un solo servicio de direcciones.

Confirme que Windows ve la interfaz antes de construir nada encima, porque todo el diseño depende de que ese adaptador sea ordinario:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

Un adaptador solo de anfitrión aparece ahí como cualquiera físico. Esa es precisamente la diferencia con el adaptador de túnel, que no se puede conectar a nada.

Traduzca el prefijo del invitado

Abra una sesión elevada y traduzca el prefijo. Compruebe primero qué existe ya, porque los entornos de ejecución de contenedores y los hipervisores instalan sus propias traducciones y borrar la incorrecta rompe otro producto.

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

Luego configure el invitado con una dirección estática en ese prefijo, 172.28.90.1 como su puerta de enlace y las direcciones de resolución que el túnel entrega al anfitrión. La traducción reenvía paquetes y no enseña nada al invitado sobre DNS, así que un invitado dejado en el router local resuelve nombres públicos y falla en todos los internos.

Compruebe el primer salto, luego el costo

Pruebe el límite más cercano antes de probar una aplicación. Un trazado que se detiene en la puerta de enlace del anfitrión significa que la traducción no ocurre, mientras que uno que se detiene más allá del anfitrión significa que el túnel está caído o que el lado remoto rechazó la dirección traducida.

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

Compárelo con el acceso propio del anfitrión al mismo destino mientras el túnel está activo. Si el anfitrión lo logra y el invitado no, la falla está en la traducción o en la configuración de puerta de enlace del invitado, no en la conexión.

Luego acepte el intercambio. Los sistemas corporativos ahora ven una dirección para cada invitado, así que los certificados de dispositivo y las comprobaciones de estado por dispositivo no pueden distinguirlos, y algunas políticas lo prohíben de plano. Decida también el comportamiento de descarte, ya que el tráfico traducido puede caer a la ruta ordinaria de internet cuando el túnel falla, salvo que bloquee ese prefijo en el firewall del anfitrión.

Artículos relacionados