El Dev Container no llega a un host solo por VPN: dónde mirar

La API privada se abre en el navegador del escritorio y falla dentro del contenedor de desarrollo. No es una contradicción y rara vez es la VPN misma. La petición del navegador y la petición que falla las hicieron procesos diferentes, con resolutores, proxys y rutas distintos, y a menudo desde espacios de nombres de red completamente distintos. «En mi portátil» puede significar el host Windows, una distribución WSL, la máquina virtual de Docker Desktop y un contenedor dentro de esa VM: cuatro contextos que pueden responder de forma distinta al mismo nombre de host. Averigüe cuál usa el proceso que falla antes de tocar un solo ajuste.

Localice el proceso antes de cambiar un ajuste

Empiece por el motor de contenedores, no por el cliente VPN. Pregunte con qué contexto habla la línea de comandos y sobre qué sistema operativo corre ese motor, porque un contenedor Linux gestionado por una VM de escritorio recorre un camino distinto del que gestiona un demonio local:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

En Windows, wsl -l -v le dice si la distribución corre bajo WSL 2, lo que la sitúa detrás de su propio conmutador virtual. Ese detalle decide si el contenedor comparte la tabla de rutas del host o queda detrás de un NAT que necesita un puerto reenviado o un nombre de host para llegar al host.

Mantenga una petición constante y compare

Elija un extremo inofensivo en el host privado y úselo para cada comparación: desde el navegador, desde una terminal del host, desde la distribución WSL y desde dentro del contenedor. Anote cuatro cosas por intento: la dirección resuelta, si se usó un proxy, la clase de fallo y el tiempo transcurrido. La resolución de nombres, el establecimiento de la conexión, la validación TLS y un estado HTTP son cuatro problemas distintos, y mezclarlos en «no funciona» desperdicia una mañana.

Ejecute la comparación dentro del contenedor que falla, con un tiempo de espera para que un cortafuegos silencioso no retenga la terminal durante minutos. Un contenedor nuevo reproduce el contexto de red del motor, pero no el espacio de nombres, las variables de proxy ni el resolutor del contenedor de la aplicación, así que docker exec dentro del contenedor real es la prueba autorizada, y un contenedor auxiliar solo sirve para aislar si la diferencia está en el motor o en el contenedor:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

La imagen base alpine trae busybox y no trae curl, y ese es justo el tipo de detalle que hace fallar un bloque de diagnóstico copiado: elija una imagen con el cliente o añádalo dentro de la misma ejecución. Una comparación con sitios públicos sin relación no aísla nada. Si https://example.com funciona desde el contenedor, ha aprendido que el contenedor tiene acceso a Internet y nada sobre si alcanza una dirección privada a través del túnel. Del mismo modo, abrir una terminal nueva solo demuestra que la terminal nueva funciona, no que comparta un entorno de ejecución con la aplicación que falló.

Docker Desktop puede funcionar con una VPN

La propia documentación de Docker sobre VPN y conectividad con el host lo describe como una configuración compatible, y el resumen honesto es que funciona en lugar de estar roto por defecto. No dé por sentado que la VM de escritorio evita el túnel del host por diseño; en muchas configuraciones el tráfico sigue correctamente el túnel del host, y por eso la leyenda de que «Docker ignora la VPN» produce consejos seguros y equivocados.

Lo que sigue importando es el backend en uso, la política de túnel dividido del cliente y la configuración del resolutor que recibió la VM. Un cliente VPN que instala rutas pero no DNS, o que empuja un servidor DNS que la VM no puede alcanzar, produce un fallo de resolución de nombres dentro del contenedor mientras el host funciona porque tiene un resolutor adicional o una respuesta en caché. Es un problema de resolutor disfrazado de contenedor. Sobrevive a cada reconexión de la VPN que intente, porque el túnel ya transporta el tráfico que le pidió.

Los solapamientos de direcciones y la MTU son fallos distintos

Dos fallos merecen su propio diagnóstico porque a menudo se confunden con la política de acceso. El primero es un solapamiento de direcciones: si la VPN empuja un rango que choca con la subred del puente por defecto de una red de contenedores, la ruta del contenedor para ese rango apunta al puente local y nunca llega al túnel. Inspeccione las subredes reales en lugar de adivinar:

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

El segundo es un problema de MTU. Si la conexión se establece y TLS se completa pero las respuestas grandes se atascan, tiene un problema de tamaño de paquete, no de autorización, y sustituir registros DNS nunca lo arreglará. Pruebe con una petición pequeña y otra grande antes de cambiar nada, y anote ambos resultados.

La solución para un solapamiento es otra subred de contenedor o una ruta acotada, elegida por quien posee el plan de direcciones. La solución para un atasco de MTU es fijar o reducir la MTU del túnel o de la interfaz a un valor que sobreviva a la ruta, aplicado en la capa que usted controla.

La configuración del proxy es por proceso, no por máquina

Dentro de un contenedor, localhost nombra el contexto de red propio de ese contenedor, así que un proxy que corre en el host no es accesible allí con ese nombre. Docker Desktop proporciona host.docker.internal para acceder al host, y en Linux lo añade explícitamente con --add-host=host.docker.internal:host-gateway. En cualquier caso, ese nombre le da una ruta hacia el host; no crea un servicio de proxy ni le autoriza a usar uno.

Use la dirección y el puerto de proxy que se proporcionan para el entorno real, y compruebe quién los lee. Las variables exportadas en un shell interactivo no configuran automáticamente cada extensión del editor, servidor de lenguaje, herramienta de compilación y demonio en segundo plano. Lo que importa es el proceso que hizo la petición que falla, así que inspeccione su entorno y no el de su terminal.

Por último, haga que la corrección se explique sola. Una resolución útil nombra la frontera que estaba mal, el ajuste que la cambió y el conjunto de procesos a los que ahora afecta. Reiniciar la VPN, el editor y el motor en secuencia puede cambiar el síntoma, pero no deja nada que la siguiente persona pueda aprovechar.