El tráfico de Windows Sandbox no sigue la VPN del host de forma predeterminada

Inicias Windows Sandbox, abres un navegador dentro y la página se carga por tu conexión habitual aunque el host estuviera en la VPN un minuto antes. No hay nada roto. El entorno aislado recibe un adaptador de red virtual conectado al conmutador predeterminado del host, y que el túnel del host cubra esa ruta es una propiedad del cliente VPN, no de Windows.

Qué recibe realmente el entorno aislado

El entorno aislado es una máquina virtual ligera con su propio adaptador de red. Ese adaptador se conecta a través del conmutador predeterminado de Hyper-V del host, que traduce el tráfico del entorno a la interfaz Ethernet virtual del host antes de que salga de la máquina. Este detalle explica casi todos los síntomas que la gente notifica al respecto.

Así que el entorno aislado no es un proceso de tu escritorio. Es un extremo de red aparte cuyos paquetes reenvía el host, y el cortafuegos del host y el cliente VPN ven ese reenvío cada uno a su manera. Una regla escrita para un proceso de navegador no coincide automáticamente con una trama traducida de un conmutador virtual.

Dos requisitos que parecen uno

Llegar a un recurso privado y forzar que cada petición del entorno aislado pase por el túnel son objetivos distintos. El primero necesita una ruta y una resolución de nombres que funcionen para el extremo del entorno. El segundo necesita una imposición que sobreviva a una reconexión y a un fallo. Ninguno se sigue del otro, y una comprobación que satisface uno no dice nada sobre el segundo.

Una comprobación de la dirección pública no responde del todo a ninguna de las dos preguntas. Ver la salida de la VPN desde dentro del entorno demuestra que parte del tráfico usó el túnel. No dice nada sobre si se resuelven los nombres privados ni sobre qué ocurre con una petición que empieza mientras el túnel está caído.

Anota cuál de los dos necesitas antes de probar nada, porque los dos requisitos llevan a diseños distintos y solo uno puede verificarse con un navegador.

Comprueba desde dentro del entorno aislado

La única observación significativa viene de la sesión del propio entorno, no del host. Abre ahí PowerShell y mira el adaptador, la resolución de nombres y la ruta hacia una dirección de documentación:

ipconfig /all
Resolve-DnsName files.corp.example
Test-NetConnection 198.51.100.7 -Port 443
Get-NetRoute -DestinationPrefix 0.0.0.0/0

La lista de adaptadores te dice la dirección y la puerta de enlace que recibió el entorno. Una puerta de enlace distinta de la del host es normal en el conmutador predeterminado, así que compara la salida en lugar de la puerta de enlace. La prueba de resolución te dice si se responde o no a un nombre privado, y aquí es donde las configuraciones split-horizon suelen divergir del host. La línea de ruta te dice qué puerta de enlace cree el entorno que es dueña de la ruta predeterminada.

Repite las mismas tres comprobaciones con el túnel conectado y desconectado. Un resultado que no cambia entre esos dos estados es prueba de que el túnel no está en la ruta del entorno en absoluto, sea cual sea la dirección que mostró la comprobación pública.

Desactiva la red cuando el entorno aislado no la necesite

Para una inspección sin conexión, un archivo de configuración personalizado puede eliminar la red por completo. El ajuste es un solo elemento del documento de configuración:

<Configuration>
  <Networking>Disable</Networking>
</Configuration>

La referencia de configuración del entorno aislado documenta este elemento y advierte de que la red activada puede exponer redes internas a aplicaciones en las que no confías. Esa advertencia es el motivo completo para fijarlo explícitamente en lugar de aceptar el valor predeterminado.

El conmutador, sin embargo, no selecciona una interfaz VPN. Es una decisión binaria sobre si hay red, no una forma de vincular el entorno a un túnel concreto. Un requisito que nombra una salida no puede satisfacerse con un conmutador que solo decide si hay una.

Diseña la frontera antes de conceder nada

Si el requisito es aislamiento estricto, elige un diseño de red de máquina virtual que pueda imponerlo, y usa la política compatible del producto VPN para el tráfico reenviado o de máquinas virtuales. Adivinar el comportamiento del cliente del host no es un diseño, y una sola comprobación exitosa no es una implementación.

No le des a un entorno no confiable un perfil de VPN corporativo ni credenciales privadas para que una prueba pase. Eso cambia la frontera que intentabas establecer por un resultado verde, y la credencial sobrevive a la prueba.

Anota el modo de red, la salida observada y el comportamiento de reconexión en las notas de despliegue. Cuando una actualización del cliente cambie cómo se trata el tráfico reenviado, esas notas son las que dicen que el requisito nunca se cumplió de verdad.