Dev-container når ikke en VPN-kun-host: hvor du bør se

Den private API-en åpnes i skrivebordsnettleseren og feiler i utviklingscontaineren. Det er ingen motsetning, og det er sjelden VPN-en selv. Nettleserforespørselen og forespørselen som feiler ble laget av ulike prosesser, med ulike resolvere, proxyer og ruter, og ofte fra helt forskjellige nettverksnavnerom. «På laptopen min» kan bety Windows-verten, en WSL-distribusjon, Docker Desktop-virtuellmaskinen og en container inne i den VM-en — fire kontekster som hver kan svare ulikt på samme vertsnavn. Finn ut hvilken den feilende prosessen bruker før du rører én eneste innstilling.

Finn prosessen før du endrer en innstilling

Start med containermotoren, ikke VPN-klienten. Spør hvilken kontekst kommandolinjen snakker med, og hvilket operativsystem den motoren kjører på, fordi en Linux-container som styres av en skrivebords-VM går en annen vei enn en som styres av en lokal daemon:

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

På Windows forteller wsl -l -v deg om distribusjonen kjører under WSL 2, noe som setter den bak sin egen virtuelle svitsj. Den detaljen avgjør om containeren deler vertens rutetabell eller sitter bak en NAT som trenger en videresendt port eller et vertsnavn for å nå verten.

Hold én forespørsel konstant og sammenlign

Velg ett ufarlig endepunkt på den private verten og bruk det til hver sammenligning: fra nettleseren, fra en vertsterminal, fra WSL-distribusjonen og fra innsiden av containeren. Noter fire ting for hvert forsøk: den løste adressen, om en proxy ble brukt, feilklassen og medgått tid. Navneoppslag, forbindelsesoppretting, TLS-validering og en HTTP-status er fire forskjellige problemer, og å blande dem til «det virker ikke» kaster bort en formiddag.

Kjør sammenligningen inne i containeren som feiler, med en timeout slik at en stille brannmur ikke holder terminalen i minutter. En fersk container gjenskaper motorens nettverkskontekst, men ikke applikasjonscontainerens navnerom, proxyvariabler eller resolver, så docker exec inn i den ekte containeren er den autoritative testen, og en sidecontainer er bare en måte å isolere om forskjellen ligger 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 en kopiert diagnostisk blokk til å feile: velg et image med klienten, eller legg den til i samme kjøring. En sammenligning med uvedkommende offentlige nettsteder isolerer ingenting. Hvis https://example.com virker fra containeren, har du lært at containeren har internettilgang, og ingenting om hvorvidt den når en privat adresse gjennom tunnelen. På samme måte beviser det å åpne en ny terminal bare at den nye terminalen virker, ikke at den deler kjøretidsmiljø med applikasjonen som feilet.

Docker Desktop kan fungere med en VPN

Dockers egen dokumentasjon om VPN og vertstilkobling beskriver dette som et støttet oppsett, og det ærlige sammendraget er at det virker i stedet for å være automatisk ødelagt. Ikke anta at skrivebords-VM-en omgår vertens tunnel som en designsak; i mange oppsett følger trafikken vertens tunnel korrekt, og derfor gir folkloren «Docker ignorerer VPN-en» selvsikre og feil råd.

Det som fortsatt betyr noe, er backend-en som brukes, klientens split-tunnel-policy og resolver-konfigurasjonen VM-en fikk. En VPN-klient som installerer ruter men ikke DNS, eller som dytter en DNS-server VM-en ikke kan nå, produserer en navneoppslagsfeil inne i containeren, mens verten virker fordi den har en ekstra resolver eller et bufret svar. Det er et resolver-problem i containerkostyme. Det overlever hver VPN-gjenoppkobling du prøver, fordi tunnelen allerede bærer trafikken du ba den bære.

Adresseoverlapp og MTU er forskjellige feil

To feil fortjener sin egen diagnose fordi de ofte forveksles med tilgangspolicy. Den første er et adresseoverlapp: hvis VPN-en dytter et område som kolliderer med et containernettverks standard-bro-undernett, peker containerens rute for det området på den lokale broen og når aldri tunnelen. Undersøk de faktiske undernettene i stedet for å gjette:

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

Den andre er et MTU-problem. Hvis forbindelsen opprettes og TLS fullføres, men større svar stopper, har du et pakkestørrelsesproblem, ikke et autorisasjonsproblem, og å bytte ut DNS-poster vil aldri fikse det. Test med en liten og en stor forespørsel før du endrer noe, og noter begge resultatene.

Løsningen på et overlapp er et annet containerundernett eller en avgrenset rute, valgt av den som eier adresseplanen. Løsningen på en MTU-stopp er å klemme eller redusere MTU-en til tunnelen eller grensesnittet til en verdi som overlever banen, brukt på laget du kontrollerer.

Proxy-konfigurasjon er per prosess, ikke per maskin

Inne i en container navngir localhost containerens eget nettverkskontekst, så en proxy som kjører på verten er ikke tilgjengelig der under det navnet. Docker Desktop tilbyr host.docker.internal for vertstilgang, og på Linux legger du det til eksplisitt med --add-host=host.docker.internal:host-gateway. Uansett gir det navnet deg en rute til verten; det oppretter ikke en proxytjeneste og autoriserer deg ikke til å bruke en.

Bruk proxyadressen og porten som er oppgitt for det faktiske miljøet, og kontroller hvem som leser dem. Variabler som eksporteres i et interaktivt skall, konfigurerer ikke automatisk hver editorutvidelse, språkserver, byggeverktøy og bakgrunnsdaemon. Det er prosessen som laget den feilende forespørselen som betyr noe, så undersøk miljøet dens i stedet for terminalens.

Til slutt, la rettelsen forklare seg selv. En nyttig løsning navngir grensen som var feil, innstillingen som endret den, og settet med prosesser den nå påvirker. Å starte VPN-en, editoren og motoren på nytt i rekkefølge kan endre symptomet, men det etterlater ingenting neste person kan bruke.