El Dev Container no arriba a un amfitrió només per VPN: on mirar

L'API privada s'obre al navegador d'escriptori i falla al contenidor de desenvolupament. Això no és cap contradicció, i poques vegades és la VPN mateixa. La petició del navegador i la petició que falla les van fer processos diferents, amb resolutors, proxys i rutes diferents, i sovint des d'espais de noms de xarxa completament diferents. «Al meu portàtil» pot voler dir l'amfitrió Windows, una distribució WSL, la màquina virtual de Docker Desktop i un contenidor dins d'aquesta VM: quatre contextos que poden respondre de manera diferent al mateix nom d'amfitrió. Esbrineu quin fa servir el procés que falla abans de tocar un sol paràmetre.

Localitzeu el procés abans de canviar un paràmetre

Comenceu pel motor de contenidors, no pel client de VPN. Pregunteu a quin context parla la línia d'ordres i sobre quin sistema operatiu s'executa aquest motor, perquè un contenidor Linux gestionat per una VM d'escriptori segueix un camí diferent del que gestiona un dimoni local:

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

A Windows, wsl -l -v us diu si la distribució s'executa sota WSL 2, cosa que la situa darrere del seu propi commutador virtual. Aquest detall decideix si el contenidor comparteix la taula d'encaminament de l'amfitrió o queda darrere d'un NAT que necessita un port reenviat o un nom d'amfitrió per arribar-hi.

Mantingueu una petició constant i compareu

Trieu un punt final inofensiu a l'amfitrió privat i feu-lo servir per a cada comparació: des del navegador, des d'un terminal de l'amfitrió, des de la distribució WSL i des de dins del contenidor. Anoteu quatre coses per a cada intent: l'adreça resolta, si s'ha fet servir un proxy, la classe de fallada i el temps transcorregut. La resolució de noms, l'establiment de la connexió, la validació TLS i un estat HTTP són quatre problemes diferents, i barrejar-los en «no funciona» malbarata un matí.

Executeu la comparació dins del contenidor que falla, amb un temps d'espera perquè un tallafocs silenciós no retingui el terminal durant minuts. Un contenidor nou reprodueix el context de xarxa del motor, però no l'espai de noms, les variables de proxy ni el resolutor del contenidor de l'aplicació, així que docker exec dins del contenidor real és la prova autoritzada, i un contenidor auxiliar només serveix per aïllar si la diferència és al motor o al contenidor:

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 imatge base alpine porta busybox i no porta curl, i aquest és exactament el tipus de detall que fa fallar un bloc de diagnòstic copiat: trieu una imatge amb el client o afegiu-lo dins de la mateixa execució. Una comparació amb llocs públics sense relació no aïlla res. Si https://example.com funciona des del contenidor, heu après que el contenidor té accés a Internet i res sobre si pot arribar a una adreça privada a través del túnel. Igualment, obrir un terminal nou només demostra que el terminal nou funciona, no que comparteixi un entorn d'execució amb l'aplicació que ha fallat.

Docker Desktop pot funcionar amb una VPN

La pròpia documentació de Docker sobre VPN i connectivitat amb l'amfitrió ho descriu com una configuració suportada, i el resum honest és que funciona en lloc d'estar trencat automàticament. No doneu per fet que la VM d'escriptori evita el túnel de l'amfitrió per disseny; en moltes configuracions el trànsit segueix correctament el túnel de l'amfitrió, i per això la llegenda que «Docker ignora la VPN» produeix consells confiats i equivocats.

El que encara importa és el backend en ús, la política de túnel dividit del client i la configuració del resolutor que ha rebut la VM. Un client VPN que instal·la rutes però no DNS, o que empeny un servidor DNS que la VM no pot assolir, produeix una fallada de resolució de noms dins del contenidor mentre l'amfitrió funciona perquè té un resolutor addicional o una resposta en memòria cau. És un problema de resolutor disfressat de contenidor. Sobrevé a cada reconnexió de la VPN que proveu, perquè el túnel ja transporta el trànsit que li heu demanat.

Els solapaments d'adreces i l'MTU són fallades diferents

Dues fallades mereixen diagnòstic propi perquè sovint es confonen amb la política d'accés. La primera és un solapament d'adreces: si la VPN empeny un rang que xoca amb la subxarxa del pont per defecte d'una xarxa de contenidors, la ruta del contenidor per a aquest rang apunta al pont local i no arriba mai al túnel. Inspeccioneu les subxarxes reals en lloc d'endevinar:

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

La segona és un problema d'MTU. Si la connexió s'estableix i TLS es completa però les respostes grans s'encallen, teniu un problema de mida de paquet, no d'autorització, i substituir registres DNS no ho arreglarà mai. Proveu amb una petició petita i una de gran abans de canviar res, i anoteu tots dos resultats.

La solució per a un solapament és una subxarxa de contenidor diferent o una ruta limitada, triada per qui posseeix el pla d'adreces. La solució per a un encallament d'MTU és fixar o reduir l'MTU del túnel o de la interfície a un valor que sobrevisqui al camí, aplicat a la capa que controleu.

La configuració del proxy és per procés, no per màquina

Dins d'un contenidor, localhost anomena el context de xarxa propi d'aquell contenidor, així que un proxy que s'executa a l'amfitrió no hi és accessible amb aquest nom. Docker Desktop proporciona host.docker.internal per accedir a l'amfitrió, i a Linux l'afegiu explícitament amb --add-host=host.docker.internal:host-gateway. De qualsevol manera, aquest nom us dona una ruta cap a l'amfitrió; no crea un servei de proxy ni us autoritza a fer-lo servir.

Feu servir l'adreça i el port de proxy que es proporcionen per a l'entorn real, i comproveu qui els llegeix. Les variables exportades en un shell interactiu no configuren automàticament cada extensió de l'editor, servidor d'idioma, eina de compilació i dimoni en segon pla. El que importa és el procés que va fer la petició que falla, així que inspeccioneu el seu entorn i no el del vostre terminal.

Finalment, feu que la correcció s'expliqui sola. Una resolució útil anomena la frontera que estava malament, el paràmetre que l'ha canviat i el conjunt de processos que ara afecta. Reiniciar la VPN, l'editor i el motor en seqüència pot canviar el símptoma, però no deixa res que la propera persona pugui aprofitar.