Den Dev Container erreecht keen nëmmen-iwwer-VPN Host: wou een no kuckt

Déi privat API geet am Desktop-Browser op a feelt am Entwécklungscontainer. Dat ass kee Widdersproch, a selten ass d'VPN selwer d'Ursaach. D'Browser-Ufro an d'Ufro déi feelt goufen vu verschiddene Prozesser gemaach, mat ënnerschiddlechen Resolveren, Proxien a Routen, an dacks aus ganz ënnerschiddlechen Netzwierk-Namensraim. „Op mengem Laptop“ kann den Windows-Host, eng WSL-Distributioun, d'Docker Desktop-VM an e Container bannent där VM bedeiten — véier Kontexter, déi allenzesummen déiselwecht Hostnumm ënnerschiddlech beäntwerten. Fannt eraus, wéi en de Prozess dee feelt benotzt, ier Dir eng eenzeg Astellung beréiert.

Fannt de Prozess, ier Dir eng Astellung ännert

Fänkt mat der Container-Engine un, net mam VPN-Client. Frot, mat wéi engem Kontext d'Kommandozeil schwätzt a wéi en Betriebssystem déi Engine leeft, well e Linux-Container deen eng Desktop-VM verwalt en anere Wee geet wéi een deen en lokalen Daemon verwalt:

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

Op Windows seet wsl -l -v Iech, ob d'Distributioun ënner WSL 2 leeft, wat se hannert hirem eegene virtuelle Switch setzt. Dës Detail entscheet, ob den Container d'Routentabelle vum Host deelt oder hannert engem NAT sëtzt, deen e weidergeleet Port oder en Hostnumm brauch fir den Host z'erreechen.

Halt eng Ufro konstant a vergläich

Wielt een harmlosen Endpunkt um private Host a benotzt en fir all Vergläich: aus dem Browser, aus engem Host-Terminal, aus der WSL-Distributioun an aus dem Container eraus. Notéiert véier Saachen pro Versuch: d'opgeléist Adress, ob en Proxy benotzt gouf, d'Fehlerklass an déi vergaangen Zäit. Nummopschlag, Verbindungsopbau, TLS-Validéierung an en HTTP-Status si véier verschidde Problemer, an se an „et funktionéiert net“ ze vermëschen kascht e Vormëtteg.

Féiert de Vergläich am Container dee feelt aus, mat engem Timeout, sou datt eng stëll Firewall den Terminal net Minutte laang hält. En neie Container reproduzéiert den Netzwierkkontext vun der Engine, awer net den Namensraum, d'Proxy-Variabelen oder de Resolver vum Applikatiounscontainer, dofir ass docker exec an den echte Container den autoritative Test, an en Sidecar ass just e Wee fir ze isoléieren, ob den Ënnerscheed an der Engine oder am Container läit:

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

D'alpine-Basisimage bréngt busybox a kee curl mat, an dat ass just déi Zort Detail déi e kopéierten Diagnoseblock feelt: wielt eng Image mam Client, oder füügt en an der selwechter Ausféierung derbäi. E Vergläich mat onverbonnenen ëffentleche Säiten isoléiert näischt. Wann https://example.com aus dem Container funktionéiert, hutt Dir geléiert datt den Container Internetzougang huet, an näischt doriwwer ob en eng privat Adress duerch den Tunnel erreecht. Gläichermoosse beweist en neien Terminal opzemaachen just datt den neien Terminal funktionéiert, net datt en eng Laufzäitumgebung mat der Applikatioun deelt déi feelt.

Docker Desktop kann mat enger VPN funktionéieren

Dem Docker seng eege Dokumentatioun iwwer VPN an Host-Konnektivitéit beschreift dëst als ënnerstëtzt Opstellung, an déi éierlech Zesummefaassung ass datt et funktionéiert amplaz automatesch futti ze sinn. Hält net ugeholl datt d'Desktop-VM den Tunnel vum Host aus Design ëmgeet; a ville Opstellungen follegt den Trafik dem Tunnel vum Host richteg, an dofir produzéiert d'Vollekserzählung „Docker ignoréiert d'VPN“ selbstsécher an falsch Rot.

Wat weider wichteg ass, ass de benotzten Backend, d'Split-Tunnel-Politik vum Client an d'Resolver-Konfiguratioun déi d'VM kritt huet. En VPN-Client deen Routen installéiert awer keen DNS, oder en DNS-Server dréckt deen d'VM net erreeche kann, produzéiert e Nummopschlag-Feeler am Container, während den Host funktionéiert well en en zousätzleche Resolver oder eng gecachte Äntwert huet. Dat ass e Resolver-Problem am Container-Kostüm. Et iwwerlieft all VPN-Remconnectioun déi Dir versicht, well den Tunnel schonn den Trafik dréit deen Dir him opgedroen hutt.

Adress-Iwwerschneidungen an MTU si verschidde Feeler

Zwee Feeler verdéngen hir eege Diagnos, well se dacks mat Zougangspolitik verwiesselt ginn. Den éischten ass eng Adress-Iwwerschneidung: wann d'VPN e Beräich dréckt deen mat dem Standard-Bridge-Subnetz vun engem Container-Netzwierk kollidéiert, weist d'Route vum Container fir dee Beräich op déi lokal Bridge an erreecht den Tunnel ni. Inspektéiert déi tatsächlech Subnetzer amplaz ze roden:

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

Den zweeten ass en MTU-Problem. Wann d'Verbindung opgebaut gëtt an TLS fäerdeg ass, awer gréisser Äntwerten hänken, hutt Dir e Pakgréisst-Problem, keen Autorisatiounsproblem, an DNS-Records ersetzen wäert et ni fixen. Testt mat enger klenger an enger grousser Ufro ier Dir eppes ännert, a notéiert béid Resultater.

D'Léisung fir eng Iwwerschneidung ass en aneren Container-Subnetz oder eng agegrenzt Route, gewielt vun deem deen den Adressplang huet. D'Léisung fir en MTU-Stopp ass d'MTU vum Tunnel oder Interface op e Wäert ze klemmen oder ze reduzéieren deen de Wee iwwersteet, ugewannt op der Schicht déi Dir kontrolléiert.

Proxy-Konfiguratioun ass pro Prozess, net pro Maschinn

Bannent engem Container nennt localhost den eegene Netzwierkkontext vun deem Container, also en Proxy deen um Host leeft ass do ënner deem Numm net erreechbar. Docker Desktop bitt host.docker.internal fir den Host-Zougang, an op Linux fügt Dir en explizit mat --add-host=host.docker.internal:host-gateway derbäi. Wéi och ëmmer, deen Numm gëtt Iech eng Route zum Host; en erstellt kee Proxy-Service a gëtt Iech net d'Recht een ze benotzen.

Benotzt d'Proxy-Adress an de Port dee fir déi tatsächlech Ëmgebung geliwwert gëtt, a kontrolléiert wien se liest. Variabelen déi an enger interaktiver Shell exportéiert ginn, konfiguréieren net automatesch all Editor-Erweiderung, Sproochserver, Build-Tool a Hannergrond-Daemon. Déi wichteg ass de Prozess deen d'Ufro déi feelt gemaach huet, also inspektéiert seng Ëmgebung an net déi vun Ärem Terminal.

Schlussendlech, loosst d'Korrektur sech selwer erklären. Eng nëtzlech Léisung nennt d'Grenz déi falsch war, d'Astellung déi se geännert huet, an de Set vu Prozesser op déi se elo beaflosst. D'VPN, den Editor an d'Engine hannerteneen nei starten kann de Symptom änneren, awer et léisst näischt zréck wat déi nächst Persoun ka benotzen.