Dev kontajner sa nedostane na hostiteľa dostupného len cez VPN: kam sa pozerať

Súkromné API sa otvorí v prehliadači na pracovnej ploche a zlyhá v kontajneri vývoja. To nie je protirečenie a málokedy je príčinou samotná VPN. Požiadavku z prehliadača a zlyhávajúcu požiadavku vytvorili rôzne procesy, s rôznymi resolvemi, proxy a trasami, a často z úplne odlišných sieťových menných priestorov. „Na mojom notebooku“ môže znamenať hostiteľa Windows, distribúciu WSL, virtuálny stroj Docker Desktop a kontajner vnútri tohto VM – štyri kontexty, z ktorých každý môže na rovnaké meno hostiteľa odpovedať inak. Zistite, ktorý z nich zlyhávajúci proces používa, skôr než sa dotknete jediného nastavenia.

Nájdite proces skôr, než zmeníte nastavenie

Začnite kontajnerovým engineom, nie VPN klientom. Opýtajte sa, s ktorým kontextom hovorí príkazový riadok a na akom operačnom systéme tento engine beží, pretože Linux kontajner spravovaný desktopovým VM ide inou cestou ako ten spravovaný lokálnym démonom:

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

V Windows wsl -l -v povie, či distribúcia beží pod WSL 2, čo ju stavia za vlastný virtuálny prepínač. Tento detail rozhoduje, či kontajner zdieľa smerovaciu tabuľku hostiteľa, alebo sedí za NAT, ktorý potrebuje presmerovaný port alebo meno hostiteľa, aby sa k hostiteľovi dostal.

Držte jednu požiadavku konštantnú a porovnávajte

Vyberte jeden neškodný koncový bod na súkromnom hostiteľovi a používajte ho pri každom porovnaní: z prehliadača, z terminálu hostiteľa, z distribúcie WSL a zvnútra kontajnera. Pri každom pokuse si zapíšte štyri veci: preloženú adresu, či bola použitá proxy, triedu zlyhania a uplynulý čas. Preklad mena, nadviazanie spojenia, validácia TLS a HTTP stav sú štyri rôzne problémy, a ich zlievanie do „nefunguje to“ premrhá celé dopoludnie.

Porovnanie spustite vnútri zlyhávajúceho kontajnera, s časovým limitom, aby tichý firewall nedržal terminál minúty. Nový kontajner reprodukuje sieťový kontext enginu, ale nie menný priestor, proxy premenné ani resolver aplikačného kontajnera, preto docker exec do skutočného kontajnera je autoritatívny test a vedľajší kontajner je len spôsob, ako izolovať, či je rozdiel v engine alebo v kontajneri:

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

Základný obraz alpine obsahuje busybox a nemá curl, a to je presne ten typ detailu, ktorý zhodí skopírovaný diagnostický blok: vyberte obraz s klientom alebo ho pridajte v tom istom spustení. Porovnanie s nesúvisiacimi verejnými stránkami nič neizoluje. Ak https://example.com funguje z kontajnera, dozvedeli ste sa, že kontajner má prístup na internet, a nič o tom, či sa tunelom dostane na súkromnú adresu. Rovnako otvorenie nového terminálu dokazuje len to, že nový terminál funguje, nie že zdieľa runtime so zlyhanou aplikáciou.

Docker Desktop môže fungovať s VPN

Vlastná dokumentácia Dockeru o VPN a konektivite k hostiteľovi to opisuje ako podporované nastavenie a úprimné zhrnutie je, že to funguje, namiesto toho aby to bolo automaticky pokazené. Nepredpokladajte, že desktopový VM obchádza tunel hostiteľa už z princípu; v mnohých nastaveniach prevádzka správne sleduje tunel hostiteľa, a práve preto folklór „Docker ignoruje VPN“ produkuje sebavedomé a zlé rady.

Čo stále záleží, je použitý backend, politika rozdeleného tunela klienta a konfigurácia resolvera, ktorú VM dostal. VPN klient, ktorý inštaluje trasy, ale nie DNS, alebo pretlačí DNS server, na ktorý sa VM nedostane, vytvára zlyhanie prekladu mena vnútri kontajnera, zatiaľ čo hostiteľ funguje, pretože má navyše resolver alebo kešovanú odpoveď. To je problém resolvera v kostýme kontajnera. Prežije každé opätovné pripojenie VPN, ktoré skúsite, pretože tunel už vezie prevádzku, o ktorú ste ho požiadali.

Prekryvy adries a MTU sú rôzne poruchy

Dve poruchy si zaslúžia vlastnú diagnostiku, pretože sa často pletú s prístupovou politikou. Prvý je prekryv adries: ak VPN pretlačí rozsah, ktorý koliduje s predvolenou podsietňou mosta kontajnerovej siete, trasa kontajnera pre tento rozsah ukazuje na lokálny most a nikdy sa nedostane do tunela. Preskúmajte skutočné podsiete, namiesto hádania:

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

Druhý je problém MTU. Ak sa spojenie nadviaže a TLS dokončí, ale väčšie odpovede sa zaseknú, máte problém veľkosti paketu, nie autorizácie, a výmena DNS záznamov to nikdy nespraví. Otestujte malú a veľkú požiadavku, skôr než čokoľvek zmeníte, a zapíšte oba výsledky.

Riešením prekryvu je iná kontajnerová podsieti alebo obmedzená trasa, ktorú vyberie ten, kto vlastní plán adries. Riešením zaseknutia MTU je stiahnutie alebo zníženie MTU tunela či rozhrania na hodnotu, ktorá cestu prežije, aplikované na vrstve, ktorú ovládate.

Konfigurácia proxy je pre proces, nie pre stroj

Vnútri kontajnera localhost pomenúva vlastný sieťový kontext tohto kontajnera, takže proxy bežiaca na hostiteľovi tam pod týmto menom dostupná nie je. Docker Desktop poskytuje host.docker.internal na prístup k hostiteľovi a v Linuxe ho pridáte výslovne pomocou --add-host=host.docker.internal:host-gateway. V každom prípade vám to meno dáva trasu k hostiteľovi; nezakladá proxy službu ani vás neoprávňuje ju používať.

Použite proxy adresu a port určené pre skutočné prostredie a skontrolujte, kto ich číta. Premenné exportované v interaktívnom shelli automaticky nenastavia každé rozšírenie editora, jazykový server, nástroj na build a background daemon. Dôležitý je proces, ktorý vytvoril zlyhávajúcu požiadavku, takže preskúmajte jeho prostredie, nie prostredie svojho terminálu.

Nakoniec, nech sa oprava vysvetlí sama. Užitočné riešenie pomenuje hranicu, ktorá bola nesprávna, nastavenie, ktoré ju zmenilo, a množinu procesov, na ktoré teraz pôsobí. Reštartovanie VPN, editora a enginu v tomto poradí môže zmeniť symptóm, ale nezanechá nič, čo by ďalší človek mohol použiť.