Dev-container kan ikke nå en VPN-kun-host: hvor du skal kigge

Den private API åbner i din skrivebordsbrowser og fejler i udviklingscontaineren. Det er ikke en modsætning, og det er sjældent VPN'en selv. Browserens anmodning og den fejlende anmodning blev lavet af forskellige processer, med forskellige resolvere, proxyer og ruter, og ofte fra helt forskellige netværksnavnerum. „På min laptop“ kan betyde Windows-værten, en WSL-distribution, Docker Desktop-virtuelmaskinen og en container inde i den VM — fire kontekster, som hver kan svare forskelligt på samme værtsnavn. Find ud af, hvilken den fejlende proces bruger, før du rører en enkelt indstilling.

Find processen, før du ændrer en indstilling

Begynd med container-motoren i stedet for VPN-klienten. Spørg, hvilken kontekst kommandolinjen taler med, og hvilket styresystem den motor kører på, fordi en Linux-container, der styres af en skrivebords-VM, går en anden vej end en, der styres af en lokal daemon:

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

På Windows fortæller wsl -l -v dig, om distributionen kører under WSL 2, hvilket sætter den bag sin egen virtuelle switch. Den detalje afgør, om containeren deler værtens routingtabel eller sidder bag en NAT, der har brug for en videresendt port eller et værtsnavn for at nå værten.

Hold én anmodning konstant og sammenlign

Vælg et harmløst endepunkt på den private vært, og brug det til hver sammenligning: fra browseren, fra en værtsterminal, fra WSL-distributionen og indefra containeren. Notér fire ting for hvert forsøg: den opløste adresse, om der blev brugt en proxy, fejlklassen og den forløbne tid. Navneopslag, forbindelsesoprettelse, TLS-validering og en HTTP-status er fire forskellige problemer, og at blande dem sammen til „det virker ikke“ spilder en formiddag.

Kør sammenligningen inde i den container, der fejler, med en timeout, så en tavs firewall ikke holder terminalen i minutter. En frisk container genskaber motorens netværkskontekst, men ikke applikationscontainerens navnerum, proxyvariabler eller resolver, så docker exec ind i den rigtige container er den autoritative test, og en sidecar er kun en måde at isolere, om forskellen 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 netop den slags detalje, der får en kopieret diagnostisk blok til at fejle: vælg et image med klienten, eller tilføj den i samme kørsel. En sammenligning med uvedkommende offentlige websteder isolerer intet. Hvis https://example.com virker fra containeren, har du lært, at containeren har internetadgang, og intet om, hvorvidt den kan nå en privat adresse gennem tunnelen. På samme måde beviser åbningen af en ny terminal kun, at den nye terminal virker, ikke at den deler runtime med den applikation, der fejlede.

Docker Desktop kan godt arbejde med en VPN

Docker's egen dokumentation om VPN og værtsforbindelse beskriver dette som en understøttet opsætning, og det ærlige resumé er, at det virker, i stedet for at være automatisk brudt. Antag ikke, at skrivebords-VM'en omgår værtens tunnel som en designmæssig ting; i mange opsætninger følger trafikken korrekt værtens tunnel, og det er derfor folkloren „Docker ignorerer VPN'en“ giver selvsikre og forkerte råd.

Det, der stadig betyder noget, er den anvendte backend, klientens split-tunnel-politik og den resolver-konfiguration, som VM'en modtog. En VPN-klient, der installerer ruter men ikke DNS, eller som skubber en DNS-server, som VM'en ikke kan nå, producerer en navneopslagsfejl inde i containeren, mens værten virker, fordi værten har en ekstra resolver eller et cachet svar. Det er et resolver-problem i containerkostume. Det overlever hver VPN-genopkobling, du forsøger, fordi tunnelen allerede bærer den trafik, du bad den bære.

Adresseoverlap og MTU er forskellige fejl

To fejl fortjener deres egen diagnose, fordi de ofte forveksles med adgangspolitik. Den første er et adresseoverlap: hvis VPN'en skubber et interval, der kolliderer med et containernetværks standard-bridge-undernet, peger containerens rute for det interval på den lokale bridge og når aldrig tunnelen. Undersøg de faktiske undernet i stedet for at gætte:

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

Den anden er et MTU-problem. Hvis forbindelsen oprettes, og TLS fuldføres, men større svar går i stå, har du et pakkestørrelsesproblem, ikke et autorisationsproblem, og udskiftning af DNS-poster vil aldrig løse det. Test med en lille anmodning og en stor, før du ændrer noget, og notér begge resultater.

Løsningen på et overlap er et andet containerundernet eller en afgrænset rute, valgt af den, der ejer adresseplanen. Løsningen på et MTU-stop er at klemme eller reducere tunnelens eller interfaceets MTU til en værdi, der overlever stien, anvendt på det lag, du kontrollerer.

Proxy-konfiguration er per proces, ikke per maskine

Inde i en container navngiver localhost containerens egen netværkskontekst, så en proxy, der kører på værten, er ikke tilgængelig der under det navn. Docker Desktop leverer host.docker.internal til værtsadgang, og på Linux tilføjer du det eksplicit med --add-host=host.docker.internal:host-gateway. Uanset hvad giver det navn dig en rute til værten; det opretter ikke en proxy-tjeneste og autoriserer dig ikke til at bruge en.

Brug den proxy-adresse og port, der er angivet for det faktiske miljø, og kontrollér, hvem der læser dem. Variabler eksporteret i en interaktiv shell konfigurerer ikke automatisk hver editorudvidelse, sprogserver, buildværktøj og baggrundsdaemon. Det er processen, der lavede den fejlende anmodning, der betyder noget, så undersøg dens miljø i stedet for din terminals.

Endelig skal rettelsen forklare sig selv. En brugbar løsning navngiver den grænse, der var forkert, den indstilling, der ændrede den, og det sæt af processer, den nu påvirker. Genstart af VPN'en, editoren og motoren i rækkefølge kan ændre symptomet, men det efterlader intet, som den næste person kan bruge.