Dev-container når ikkje ein VPN-berre vert: kvar du bør sjå

Den private API-en opnar i skrivebordsnettlesaren og feilar i utviklingscontaineren. Det er ingen motseiing, og det er sjeldan VPN-en sjølv. Nettlesarførespurnaden og førespurnaden som feilar vart laga av ulike prosessar, med ulike resolverar, proxyar og ruter, og ofte frå heilt ulike nettverksnamnerom. «På laptopen min» kan tyde Windows-verten, ein WSL-distribusjon, Docker Desktop-virtuellmaskinen og ein container inne i den VM-en — fire kontekstar som kvar kan svare ulikt på same vertsnamn. Finn ut kva den feilande prosessen brukar før du rører éi einaste innstilling.

Finn prosessen før du endrar ei innstilling

Start med containermotoren, ikkje VPN-klienten. Spør kva kontekst kommandolinja snakkar med, og kva operativsystem den motoren køyrer på, fordi ein Linux-container som vert styrt av ein skrivebords-VM går ein annan veg enn ein som vert styrt av ein lokal daemon:

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

På Windows fortel wsl -l -v deg om distribusjonen køyrer under WSL 2, noko som set han bak sin eigen virtuelle svitsj. Den detaljen avgjer om containeren deler rutetabellen til verten eller sit bak ein NAT som treng ein vidaresend port eller eit vertsnamn for å nå verten.

Hald éin førespurnad konstant og samanlikn

Vel eitt ufarleg endepunkt på den private verten og bruk det til kvar samanlikning: frå nettlesaren, frå ein vertsterminal, frå WSL-distribusjonen og frå innsida av containeren. Noter fire ting for kvart forsøk: den løyste adressa, om ein proxy vart brukt, feilklassen og medgåen tid. Namneoppslag, sambandsoppretting, TLS-validering og ein HTTP-status er fire ulike problem, og å blande dei til «det verkar ikkje» kastar bort ein formiddag.

Køyr samanlikninga inne i containeren som feilar, med ein timeout slik at ein stille brannmur ikkje held terminalen i minutt. Ein fersk container attskapar nettverkskonteksten til motoren, men ikkje namnerommet, proxyvariablane eller resolveren til applikasjonscontaineren, så docker exec inn i den ekte containeren er den autoritative testen, og ein sidecontainer er berre ein måte å isolere om skilnaden ligg i motoren eller i containeren:

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

alpine-basisimaget har busybox og ingen curl, og det er nettopp den typen detalj som får ein kopiert diagnostisk blokk til å feile: vel eit image med klienten, eller legg han til i same køyring. Ei samanlikning med uvedkomande offentlege nettstader isolerer ingenting. Viss https://example.com verkar frå containeren, har du lært at containeren har internettilgang, og ingenting om han når ei privat adresse gjennom tunnelen. På same måte beviser det å opne ein ny terminal berre at den nye terminalen verkar, ikkje at han deler køyretidsmiljø med applikasjonen som feila.

Docker Desktop kan fungere med ein VPN

Dockers eigen dokumentasjon om VPN og vertstilkopling skildrar dette som eit støtta oppsett, og det ærlege samandraget er at det verkar i staden for å vere automatisk øydelagt. Ikkje gå ut frå at skrivebords-VM-en omgår tunnelen til verten som ei designsak; i mange oppsett følgjer trafikken tunnelen til verten korrekt, og difor gir folkeminne «Docker ignorerer VPN-en» sjølvsikre og feil råd.

Det som framleis betyr noko, er backend-en som vert brukt, split-tunnel-politikken til klienten og resolver-konfigurasjonen VM-en fekk. Ein VPN-klient som installerer ruter men ikkje DNS, eller som dyttar ein DNS-server VM-en ikkje kan nå, produserer ein namneoppslagsfeil inne i containeren, medan verten verkar fordi han har ein ekstra resolver eller eit bufra svar. Det er eit resolver-problem i containerkostyme. Det overlever kvar VPN-attkopling du prøver, fordi tunnelen allereie ber trafikken du bad han bere.

Adresseoverlapp og MTU er ulike feil

To feil fortener si eiga diagnose fordi dei ofte vert forveksla med tilgangspolitikk. Den første er eit adresseoverlapp: viss VPN-en dyttar eit område som kolliderer med standard-bru-underdelen av eit containernettverk, peikar ruta til containeren for det området på den lokale brua og når aldri tunnelen. Undersøk dei faktiske underdela i staden for å gjette:

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

Den andre er eit MTU-problem. Viss sambandet vert oppretta og TLS fullført, men større svar stoppar, har du eit pakkestorleiksproblem, ikkje eit autorisasjonsproblem, og å byte ut DNS-poster vil aldri fikse det. Test med ein liten og ein stor førespurnad før du endrar noko, og noter båe resultata.

Løysinga på eit overlapp er eit anna containerunderdel eller ei avgrensa rute, vald av den som eig adresseplanen. Løysinga på ein MTU-stopp er å klemme eller redusere MTU-en til tunnelen eller grensesnittet til ein verdi som overlever banen, brukt på laget du styrer.

Proxy-konfigurasjon er per prosess, ikkje per maskin

Inne i ein container namngjev localhost nettverkskonteksten til containeren sjølv, så ein proxy som køyrer på verten er ikkje tilgjengeleg der under det namnet. Docker Desktop tilbyr host.docker.internal for vertstilgang, og på Linux legg du han til eksplisitt med --add-host=host.docker.internal:host-gateway. Uansett gir det namnet deg ei rute til verten; det opprettar ikkje ein proxiteneste og gjev deg ikkje løyve til å bruke ein.

Bruk proxyadressa og porten som er oppgjevne for det faktiske miljøet, og kontroller kven som les dei. Variablar som vert eksporterte i eit interaktivt skal, konfigurerer ikkje automatisk kvar editorutviding, språkserver, byggjeverktøy og bakgrunnsdaemon. Det er prosessen som laga den feilande førespurnaden som betyr noko, så undersøk miljøet hans i staden for terminalen sitt.

Til slutt, la rettinga forklare seg sjølv. Ei nyttig løysing namngjev grensa som var feil, innstillinga som endra henne, og settet med prosessar ho no påverkar. Å starte VPN-en, editoren og motoren på nytt i rekkjefølgje kan endre symptomet, men det etterlèt ingenting neste person kan bruke.