Dev Container berikt gjin host dy't allinnich fia VPN te berikken is: wêr't jo sykje moatte

De partikuliere API iepenet yn jo desktop-browser en mislearret yn 'e ûntwikkelcontainer. Dat is gjin tsjinstelling, en it is selden de VPN sels. It fersyk fan 'e browser en it mislearjende fersyk binne dien troch ferskate prosessen, mei ferskate resolvers, proxy's en rûtes, en faak út folslein ferskate netwurknammeromten. “Op myn laptop” kin de Windows-host, in WSL-distribúsje, de Docker Desktop-firtuele masine en in container binnen dy VM betsjutte — fjouwer konteksten dy't elk itselde hostnamme oars beantwurdzje kinne. Untdek hokker de mislearjende proses brûkt foardat jo ien ynstelling oanreitsje.

Fyn de proses foardat jo in ynstelling feroarje

Begjin mei de containermotor, net mei de VPN-klant. Freegje hokker kontekst de kommandorigel mei praat en op hokker bestjoeringssysteem dy motor draait, want in Linux-container dy't troch in desktop-VM beheard wurdt giet in oare wei as ien dy't troch in lokale daemon beheard wurdt:

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

Op Windows fertelt wsl -l -v jo oft de distribúsje ûnder WSL 2 draait, wat it efter syn eigen firtuele skeakel set. Dat detail beslút oft de container de rûtetabel fan 'e host dielt of efter in NAT sit dy't in trochstjoerde poarte of in hostnamme nedich hat om de host te berikken.

Hâld ien fersyk konstant en fergelykje

Kies ien harmleas einpunt op 'e partikuliere host en brûk it foar elke fergeliking: fan 'e browser, fan in hostterminal, fan 'e WSL-distribúsje en fan binnen de container. Skriuw fjouwer dingen del foar elke poging: it oploste adres, oft in proxy brûkt is, de flaterklasse en de ferstrutsen tiid. Namme-opfrege, ferbiningopbou, TLS-falidaasje en in HTTP-status binne fjouwer ferskate problemen, en se te mingen yn “it wurket net” fergriemt in moarntiid.

Fier de fergeliking út binnen de container dy't mislearret, mei in tiidlimit sadat in stille firewall de terminal net minutenlang beset hâldt. In nije container reprodusearret de netwurkekontekst fan 'e motor, mar net de nammeromte, proxyfariabelen of resolver fan 'e applikaasjecontainer, dus docker exec yn 'e echte container is de autoritative test, en in sydcontainer is allinnich in manier om te isolearjen oft it ferskil yn 'e motor of yn 'e container sit:

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

De alpine-basisôfbylding hat busybox en gjin curl, en dat is krekt it soarte detail dat in kopyearre diagnostyske blok mislearje lit: kies in ôfbylding mei de klant, of foegje it yn deselde run ta. In fergeliking mei net besibbe publike siden isolearret neat. As https://example.com fan 'e container ôf wurket, hawwe jo leard dat de container ynternettagong hat, en neat oer oft er in partikulier adres fia de tunnel berikke kin. Likegoed bewiist it iepenjen fan in nije terminal allinnich dat de nije terminal wurket, net dat er in runtime dielt mei de applikaasje dy't mislearre.

Docker Desktop kin mei in VPN wurkje

Docker syn eigen dokumintaasje oer VPN en hostferbining beskriuwt dit as in stipe opset, en de earlike gearfetting is dat it wurket ynstee fan automatysk stikken te wêzen. Nim net oan dat de desktop-VM de tunnel fan 'e host by ûntwerp omgiet; yn in protte opsetten folget it ferkear de tunnel fan 'e host korrekt, en dêrom jout de folksfertelling “Docker negearret de VPN” selsbetrouwe en ferkearde advizen.

Wat noch fan belang is, is de brûkte backend, it split-tunnelbelied fan 'e klant en de resolverkonfiguraasje dy't de VM krigen hat. In VPN-klant dy't rûtes ynstallearret mar gjin DNS, of dy't in DNS-tsjinner pusht dy't de VM net berikke kin, produsearret in namme-opfregingsflater binnen de container wylst de host wurket om't de host in ekstra resolver of in cache-antwurd hat. Dat is in resolverprobleem yn in containerkostúm. It oerlibbet elke VPN-ferbining dy't jo besykje, om't de tunnel al it ferkear draacht dat jo him fregen te dragen.

Adresoerlappen en MTU binne ferskate flaters

Twa flaters fertsjinje har eigen diagnoaze om't se faak mei tagongsbelied betize wurde. De earste is in adresoerlap: as de VPN in berik pusht dat botsing makket mei it standertbrêge-subnet fan in containernetwurk, wiist de rûte fan 'e container foar dat berik nei de lokale brêge en berikt de tunnel nea. Undersykje de echte subnets ynstee fan te rieden:

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

De twadde is in MTU-probleem. As de ferbining ta stân komt en TLS foltôget, mar gruttere antwurden stûkje, hawwe jo in pakketgrutteprobleem, gjin autorisaasjeprobleem, en it ferfangen fan DNS-records sil it nea reparearje. Test mei in lyts fersyk en in grut ien foardat jo wat feroarje, en skriuw beide útkomsten del.

De oplossing foar in oerlap is in oar containersubnet of in beheinde rûte, keazen troch wa't it adresplan hat. De oplossing foar in MTU-stûking is it knypen of ferleegjen fan 'e MTU fan 'e tunnel of interface nei in wearde dy't it paad oerlibbet, tapast op 'e laach dy't jo beheare.

Proxykonfiguraasje is per proses, net per masine

Binnen in container neamt localhost de eigen netwurkekontekst fan dy container, dus in proxy dy't op 'e host draait is dêr net ûnder dy namme te berikken. Docker Desktop biedt host.docker.internal foar hosttagong, en op Linux foegje jo it eksplisyt ta mei --add-host=host.docker.internal:host-gateway. Hoe dan ek, dy namme jout jo in rûte nei de host; it makket gjin proxyservice en autorisearret jo net om ien te brûken.

Brûk it proxyadres en de poarte dy't foar de echte omjouwing jûn binne, en kontrolearje wa't se lêst. Fariabelen dy't yn in ynteraktive shell eksportearre wurde, konfigurearje net automatysk elke bewurker-útwreiding, taalserver, build-ark en eftergrûndaemon. De iene dy't fan belang is, is de proses dy't it mislearjende fersyk dien hat, dus ûndersykje syn omjouwing ynstee fan dy fan jo terminal.

Ta beslút, lit de reparaasje himsels útlisje. In nuttige oplossing neamt de grins dy't ferkeard wie, de ynstelling dy't it feroare hat, en de set prosessen dy't it no beynfloedet. It opnij starten fan 'e VPN, de bewurker en de motor yn folchoarder kin it symptoom feroarje, mar it lit neat efter dat de folgjende persoan brûke kin.