O Dev Container non chega a unha máquina só por VPN: onde mirar

A API privada ábrese no navegador de escritorio e falla dentro do contedor de desenvolvemento. Non é unha contradición e rara vez é a VPN mesma. A petición do navegador e a petición que falla fixéronas procesos diferentes, con resolvedores, proxies e rutas distintos, e a miúdo desde espazos de nomes de rede completamente distintos. «No meu portátil» pode significar a máquina Windows, unha distribución WSL, a máquina virtual de Docker Desktop e un contedor dentro desa VM: catro contextos que poden responder de forma distinta ao mesmo nome de máquina. Descubra cal usa o proceso que falla antes de tocar un só axuste.

Localice o proceso antes de cambiar un axuste

Comece polo motor de contedores, non polo cliente VPN. Pregunte con que contexto fala a liña de ordes e sobre que sistema operativo se executa ese motor, porque un contedor Linux xestionado por unha VM de escritorio segue un camiño distinto do que xestiona un daemon local:

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

En Windows, wsl -l -v dille se a distribución se executa baixo WSL 2, o que a sitúa detrás do seu propio conmutador virtual. Ese detalle decide se o contedor comparte a táboa de rutas da máquina ou queda detrás dun NAT que necesita un porto reenviado ou un nome de máquina para chegar a ela.

Manteña unha petición constante e compare

Escolla un extremo inofensivo na máquina privada e úseo para cada comparación: desde o navegador, desde un terminal da máquina, desde a distribución WSL e desde dentro do contedor. Anote catro cousas por intento: o enderezo resolto, se se usou un proxy, a clase de fallo e o tempo transcorrido. A resolución de nomes, o establecemento da conexión, a validación TLS e un estado HTTP son catro problemas distintos, e mesturalos en «non funciona» desperdicia unha mañá.

Execute a comparación dentro do contedor que falla, cun tempo de espera para que unha devasa silenciosa non retarde o terminal durante minutos. Un contedor novo reproduce o contexto de rede do motor, pero non o espazo de nomes, as variables de proxy nin o resolvedor do contedor da aplicación, así que docker exec dentro do contedor real é a proba autorizada, e un contedor auxiliar só serve para illar se a diferenza está no motor ou no contedor:

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

A imaxe base alpine trae busybox e non trae curl, e ese é xusto o tipo de detalle que fai fallar un bloque de diagnóstico copiado: escolla unha imaxe co cliente ou engádao dentro da mesma execución. Unha comparación con sitios públicos sen relación non illa nada. Se https://example.com funciona desde o contedor, aprendeu que o contedor ten acceso a Internet e nada sobre se alcanza un enderezo privado a través do túnel. Do mesmo xeito, abrir un terminal novo só demostra que o terminal novo funciona, non que comparta un contorno de execución coa aplicación que fallou.

Docker Desktop pode funcionar cunha VPN

A propia documentación de Docker sobre VPN e conectividade coa máquina descríbeo como unha configuración compatible, e o resumo honesto é que funciona en lugar de estar roto por defecto. Non dea por sentado que a VM de escritorio evita o túnel da máquina por deseño; en moitas configuracións o tráfico segue correctamente o túnel da máquina, e por iso a lenda de que «Docker ignora a VPN» produce consellos seguros e equivocados.

O que segue importando é o backend en uso, a política de túnel dividido do cliente e a configuración do resolvedor que recibiu a VM. Un cliente VPN que instala rutas pero non DNS, ou que empurra un servidor DNS que a VM non pode alcanzar, produce un fallo de resolución de nomes dentro do contedor mentres a máquina funciona porque ten un resolvedor adicional ou unha resposta na caché. É un problema de resolvedor disfrazado de contedor. Sobrevive a cada reconexión da VPN que tente, porque o túnel xa transporta o tráfico que lle pediu.

Os solapamentos de enderezos e a MTU son fallos distintos

Dous fallos merecen o seu propio diagnóstico porque a miúdo confúndense coa política de acceso. O primeiro é un solapamento de enderezos: se a VPN empurra un rango que choca coa subrede da ponte por defecto dunha rede de contedores, a ruta do contedor para ese rango apunta á ponte local e nunca chega ao túnel. Inspeccione as subredes reais en lugar de adiviñar:

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

O segundo é un problema de MTU. Se a conexión se estabelece e TLS se completa pero as respostas grandes se atascan, ten un problema de tamaño de paquete, non de autorización, e substituír rexistros DNS nunca o arranxará. Probe cunha petición pequena e outra grande antes de cambiar nada, e anote ambos os resultados.

A solución para un solapamento é outra subrede de contedor ou unha ruta restrinxida, escollida por quen posúe o plan de enderezos. A solución para un atasco de MTU é fixar ou reducir a MTU do túnel ou da interface a un valor que sobreviva á ruta, aplicado na capa que vostede controla.

A configuración do proxy é por proceso, non por máquina

Dentro dun contedor, localhost nomea o contexto de rede propio dese contedor, así que un proxy que se executa na máquina non é accesible alí con ese nome. Docker Desktop proporciona host.docker.internal para acceder á máquina, e en Linux engádeo explicitamente con --add-host=host.docker.internal:host-gateway. De calquera xeito, ese nome dálle unha ruta cara á máquina; non crea un servizo de proxy nin o autoriza a usar un.

Use o enderezo e o porto de proxy que se proporcionan para o contorno real, e comprobe quen os le. As variables exportadas nun shell interactivo non configuran automaticamente cada extensión do editor, servidor de linguaxe, ferramenta de compilación e daemon en segundo plano. O que importa é o proceso que fixo a petición que falla, así que inspeccione o seu contorno e non o do seu terminal.

Por último, faga que a corrección se explique soa. Unha resolución útil nomea a fronteira que estaba mal, o axuste que a cambiou e o conxunto de procesos aos que agora afecta. Reiniciar a VPN, o editor e o motor en secuencia pode cambiar o síntoma, pero non deixa nada que a seguinte persoa poida aproveitar.