Contenedores de Windows y VPN: por qué falla la red local
Un contenedor de Windows usa la tabla de rutas del host, así que una VPN que bloquea la subred local se lleva consigo el prefijo del contenedor. El modo Linux toma otro camino.
En un solo portátil, con un solo cliente VPN conectado, los contenedores de Linux siguen hablando entre sí y los de Windows se detienen en seco. La imagen no es la variable; el camino que toman los paquetes hacia el host sí lo es. Los contenedores de Windows en la red predeterminada toman prestada la tabla de rutas y la traducción del host, así que una política que cambia el enrutamiento del host también los cambia a ellos. Confírmelo con una consulta de rutas antes de reinstalar nada.
Dónde entran los paquetes de un contenedor de Windows en el host
Un contenedor en la red predeterminada nat obtiene una dirección de un prefijo del servicio Host Networking Service, normalmente en algún punto dentro de 172.16.0.0/12, y llega al host mediante un adaptador virtual. El host es dueño de la ruta de ese prefijo y traduce el tráfico hacia el adaptador que esté activo. No hay ninguna máquina virtual separada en medio de ese camino.
Ese diseño es lo que hace mecánico el fallo. Cuando el contenedor envía un paquete, el host realiza una consulta de ruta para el prefijo del contenedor. La ruta que gane es adonde va el paquete, y el contenedor no tiene opinión sobre eso.
Qué cambia el cliente VPN en ese camino
Un cliente corporativo suele instalar un amplio conjunto de rutas y un filtro que deniega el acceso a la subred local mientras el túnel está activo. La intención es defensiva: una red local comprometida no debería llegar a una máquina protegida. El efecto secundario es que la ruta del host hacia el prefijo del contenedor ya no es la red NAT local.
En cambio, la consulta coincide con el túnel y el paquete se entrega a la puerta de enlace, que nunca ha oído hablar de esa dirección de contenedor. El ping falla, la aplicación agota el tiempo de espera y el contenedor parece roto mientras el icono de la VPN brilla. Mire la tabla del host mientras está conectado y la ruta competidora queda visible.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Por qué los contenedores de Linux se comportan de otra manera
El motor de Linux ejecuta los contenedores dentro de una máquina virtual ligera, y las conexiones salientes de esa máquina las abre un proxy del lado del host en nombre del contenedor. El host inicia el socket, así que la regla de la VPN sobre el prefijo del contenedor no se le aplica del mismo modo, y la carga de trabajo sigue llegando a la red.
Esa diferencia también explica por qué las recetas de Linux no se trasladan. A un contenedor de Linux que necesita su propio túnel se le da un dispositivo TUN más la capacidad NET_ADMIN. Los contenedores de Windows no exponen ninguna interfaz como dispositivo, así que ese patrón no tiene equivalente en ese lado.
Demuestre la ruta y después elija un diseño
Recoja pruebas del host, no del contenedor, porque el host es quien hace la consulta:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Ejecute la salida de rutas una vez antes de que se conecte la VPN y una vez después. Si en la segunda salida el prefijo del contenedor apunta al adaptador del túnel, el diagnóstico está completo y reiniciar los contenedores no ayudará.
La primera opción es una decisión de política: pregunte al propietario de la red si se puede permitir el acceso a la LAN local para este dispositivo. Varios clientes corporativos lo ofrecen como ajuste, pero debilita una frontera deliberada. Pídalo como una excepción documentada con un propietario y una fecha de revisión. Un interruptor por dispositivo al que nadie vuelve es la forma en que una política defensiva desaparece en silencio.
Donde la política debe mantenerse, mueva la carga de trabajo en lugar de pelear con la ruta. Una red transparente con una subred y una puerta de enlace explícitas pone los contenedores en el enlace local, una carga de trabajo de Linux se ejecuta detrás del proxy de la máquina virtual, y una máquina virtual separada con su propio cliente conserva su propia política. Elija una a propósito y pruébela desde dentro del contenedor, porque es ahí donde se origina la petición del usuario.