Dev Container-ak ezin du VPN bidez soilik eskuragarri dagoen host batera iritsi: nondik begiratu

API pribatua mahaigaineko nabigatzailean irekitzen da eta garapen-kontenedorean huts egiten du. Hori ez da kontraesan bat, eta gutxitan da VPN bera erruduna. Nabigatzailearen eskaera eta huts egiten duen eskaera prozesu desberdinek egin zituzten, resolver, proxy eta ibilbide desberdinekin, eta askotan sare-izen-espazio erabat desberdinetatik. «Nire ordenagailuan» Windows ostalaria, WSL banaketa, Docker Desktop makina birtuala eta VM horren barruko kontenedore bat esan nahi izan dezake: lau testuinguru, eta bakoitzak host-izen berari modu desberdinean erantzun diezaioke. Argitu zein erabiltzen duen huts egiten duen prozesuak ezarpen bakarrean ukitu aurretik.

Aurkitu prozesua, ezarpena aldatu aurretik

Hasi kontenedore-motorrarekin, ez VPN bezeroarekin. Galdetu zein testuingururekin hitz egiten duen komando-lerroak eta zein sistema eragiletan exekutatzen den motor hori, mahai-gaineko VM batek kudeatutako Linux kontenedoreak bide desberdina egiten baitu daemon lokal batek kudeatutakoak baino:

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

Windowsen, wsl -l -v-ek esaten du banaketa WSL 2ren pean exekutatzen den ala ez, eta horrek bere switch birtualaren atzean jartzen du. Xehetasun horrek erabakitzen du kontenedoreak ostalariaren bideratze-taula partekatzen duen edo NAT baten atzean dagoen, aurrera eramandako portu bat edo ostalari-izen bat behar duena ostalarira iristeko.

Mantendu eskaera bat konstante eta alderatu

Hautatu amaiera-puntu kaltegabe bat host pribatuan eta erabili alderaketa bakoitzerako: nabigatzailetik, ostalariaren terminaletik, WSL banaketatik eta kontenedorearen barrutik. Idatzi lau gauza saiakera bakoitzeko: ebatzitako helbidea, proxy bat erabili den, huts-motaren klasea eta igarotako denbora. Izen-ebazpena, konexioaren ezarpena, TLS baliozkotzea eta HTTP egoera lau arazo desberdin dira, eta horiek «ez du funtzionatzen» esaldian nahasteak goiz oso bat alferrik galtzen du.

Exekutatu alderaketa huts egiten duen kontenedorearen barruan, denbora-muga batekin, suebaki isil batek terminala minututan euts ez dezan. Kontenedore berri batek motorraren sare-testuingurua birsortzen du, baina ez aplikazioaren kontenedorearen izen-espazioa, proxy aldagaiak edo resolverra, beraz docker exec benetako kontenedorera sartzea da proba autoritarioa, eta alboko kontenedorea motorraren eta kontenedorearen arteko aldea isolatzeko modu bat baino ez da:

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 oinarrizko irudiak busybox dakar eta ez du curl, eta hori da kopiatutako diagnostiko-bloke bat hutsarazten duen xehetasun mota: aukeratu bezeroa duen irudi bat, edo gehitu hura exekuzio berean. Erlazionik gabeko webgune publikoeekin alderatzeak ez du ezer isolatzen. Kontenedoretik https://example.com funtzionatzen badu, kontenedoreak interneteko sarbidea duela ikasi duzu, eta ezer ez tuneletik helbide pribatu batera iristen den ala ez. Era berean, terminal berri bat irekitzeak terminal berria funtzionatzen duela frogatzen du soilik, ez duela huts egin zuen aplikazioarekin exekuzio-ingurune bera partekatzen.

Docker Desktop-ek VPN batekin funtziona dezake

Dockerren beraren VPN eta ostalari-konektibitateari buruzko dokumentazioak konfigurazio onartutzat deskribatzen du, eta laburpen zintzoa da funtzionatzen duela, ez dagoela automatikoki hautsita. Ez ezazu pentsa mahaigaineko VMak ostalariaren tunela diseinuz saihesten duenik; konfigurazio askotan trafikoak ostalariaren tunela behar bezala jarraitzen du, eta horregatik «Dockerrek VPNa alde batera uzten du» kondairak aholku seguru eta okerrak sortzen ditu.

Oraindik garrantzitsua da erabilitako backend-a, bezeroaren split-tunnel politika eta VMak jaso zuen resolver konfigurazioa. Bideak instalatzen dituen baina DNS ez duen VPN bezero batek, edo VMak iristeko modurik ez duen DNS zerbitzari bat bultzatzen duenak, izen-ebazpen hutsegitea kontenedorearen barruan sortzen du, ostalaria funtzionatzen duen bitartean, ostalariak resolver gehigarri bat edo cachean gordetako erantzun bat duelako. Resolver arazoa da, kontenedorearen mozorroarekin. Saiatzen duzun VPN berrikonexio bakoitzari eusten dio, tunelak jada eskatutako trafikoa daramalako.

Helbide-gainjartzeak eta MTU huts desberdinak dira

Bi hutsek beren diagnostikoa merezi dute, sarritan sarbide-politikatzat hartzen baitira. Lehenengoa helbide-gainjartzea da: VPNak kontenedore-sare baten zubi lehenetsiaren azpisarearekin talka egiten duen barruti bat bultzatzen badu, barruti horretarako kontenedorearen ibilbideak tokiko zubira seinalatzen du eta ez da inoiz tunelera iristen. Aztertu benetako azpisareak, asmatu beharrean:

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

Bigarrena MTU arazoa da. Konexioa ezartzen bada eta TLS osatzen bada, baina erantzun handiagoak blokeatzen badira, pakete-tamainaren arazoa duzu, ez autorizazioarena, eta DNS erregistroak ordezkatzeak ez du inoiz konponduko. Probatu eskaera txiki batekin eta handi batekin ezer aldatu aurretik, eta idatzi bi emaitzak.

Gainjartzearen konponbidea kontenedore-azpisare desberdin bat edo ibilbide mugatu bat da, helbide-plana duenak aukeratua. MTU blokeoaren konponbidea tunelaren edo interfazearen MTU bidea gainditzen duen balio batera estutzea edo murriztea da, kontrolatzen duzun geruzan aplikatuta.

Proxy konfigurazioa prozesu bakoitzeko da, ez makinako

Kontenedore baten barruan, localhost kontenedore horren beraren sare-testuinguruari egiten dio erreferentzia, beraz ostalarian exekutatzen den proxy bat ez da han izen horrekin eskuragarri. Docker Desktopek host.docker.internal ematen du ostalarirako sarbiderako, eta Linuxen esplizituki gehitzen duzu --add-host=host.docker.internal:host-gateway erabiliz. Edonola ere, izen horrek ostalarirako ibilbide bat ematen dizu; ez du proxy zerbitzurik sortzen eta ez dizu bat erabiltzeko baimenik ematen.

Erabili benetako ingurunerako emandako proxy helbidea eta portua, eta egiaztatu nor ari den irakurtzen. Shell interaktibo batean esportatutako aldagaiek ez dituzte automatikoki konfiguratzen editorearen luzapen guztiak, hizkuntza-zerbitzaria, eraikuntza-tresna eta atzeko planoko daemona. Garrantzitsua dena huts egin zuen eskaera egin zuen prozesua da, beraz aztertu haren ingurunea, ez zure terminalarena.

Azkenik, egin konponketak bere burua azal dezan. Konponbide erabilgarri batek oker zegoen muga izendatzen du, aldatu zuen ezarpena eta orain eragiten dien prozesuen multzoa. VPNa, editorea eta motorra segidan berrabiarazteak sintoma alda dezake, baina ez du hurrengo pertsonak erabil dezakeen ezer uzten.