Hindi maabot ng dev container ang host na VPN-only: saan titingin

Nagbubukas ang pribadong API sa browser ng iyong desktop at nabibigo sa dev container. Hindi iyon kontradiksyon, at bihirang ang VPN mismo ang dahilan. Ang kahilingan ng browser at ang nabigong kahilingan ay ginawa ng magkaibang proseso, may magkaibang resolver, proxy at ruta, at madalas mula sa lubos na magkaibang network namespace. Ang "sa laptop ko" ay maaaring mangahulugan ng Windows host, isang WSL distribution, ang Docker Desktop virtual machine at isang container sa loob ng VM na iyon, apat na konteksto na bawat isa ay maaaring magkaibang sumagot sa parehong hostname. Alamin kung alin ang ginagamit ng prosesong nabibigo bago mo hawakan ang kahit isang setting.

Hanapin ang proseso bago magbago ng setting

Magsimula sa container engine sa halip na sa VPN client. Itanong kung anong konteksto ang kausap ng command line, at kung anong operating system ang pinapatakbo ng engine na iyon, dahil ang Linux container na pinamamahalaan ng desktop VM ay ibang landas kaysa sa pinamamahalaan ng lokal na daemon:

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

Sa Windows, sinasabi ng wsl -l -v kung tumatakbo ang distribution sa ilalim ng WSL 2, na naglalagay dito sa likod ng sarili nitong virtual switch. Ang detalyeng iyon ang nagtatakda kung ang container ay nagbabahagi ng routing table ng host o nasa likod ng NAT na nangangailangan ng forwarded port o host name para maabot ang host.

Panatilihing pare-pareho ang isang kahilingan at maghambing

Pumili ng isang hindi mapanganib na endpoint sa pribadong host at gamitin iyon sa bawat paghahambing, mula sa browser, mula sa terminal ng host, mula sa WSL distribution at mula sa loob ng container. Itala ang apat na bagay sa bawat pagtatangka: ang naresolbang address, kung may proxy na ginamit, ang klase ng pagbigo at ang lumipas na oras. Ang paghahanap ng pangalan, pagtatatag ng koneksyon, pagpapatunay ng TLS at isang HTTP status ay apat na magkaibang problema, at ang pagsasama-sama ng mga ito sa "hindi gumagana" ay nagsasayang ng isang umaga.

Patakbuhin ang paghahambing sa loob ng container na nabibigo, may timeout upang ang tahimik na firewall ay hindi hawakan ang terminal nang ilang minuto. Ang bagong container ay nagre-reproduce ng network context ng engine ngunit hindi ang namespace, proxy variables o resolver ng application container, kaya ang docker exec papunta sa tunay ay ang awtoritatibong pagsubok at ang sidecar ay paraan lamang upang ihiwalay kung ang pagkakaiba ay ang engine o ang container:

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

Ang alpine base image ay may busybox at walang curl, at iyon mismo ang uri ng detalye na nagpapabigo sa kinopyang diagnostic block: pumili ng image na may client, o idagdag ito sa loob ng parehong run. Ang paghahambing sa walang kaugnayang pampublikong site ay walang inihihiwalay. Kung gumagana ang https://example.com mula sa container, nalaman mo na may internet access ang container at wala tungkol sa kung maaabot nito ang pribadong address sa pamamagitan ng tunnel. Gayundin, ang pagbukas ng bagong terminal ay nagpapatunay lamang na gumagana ang bagong terminal, hindi na nagbabahagi ito ng runtime sa application na nabigo.

Maaaring gumana ang Docker Desktop kasama ng VPN

Ang sariling dokumentasyon ng Docker tungkol sa VPN at koneksyon sa host ay inilalarawan ito bilang sinusuportahang setup, at ang tapat na buod ay gumagana ito sa halip na awtomatikong sira. Huwag ipalagay na nilalampasan ng desktop VM ang tunnel ng host bilang usapin ng disenyo; sa maraming setup, sinusunod ng trapiko ang tunnel ng host nang tama, kaya ang alamat na "binabalewala ng Docker ang VPN" ay nagbubunga ng matatag ngunit maling payo.

Ang mahalaga pa rin ay ang backend na ginagamit, ang patakaran ng split tunnel ng client, at ang resolver configuration na natanggap ng VM. Ang VPN client na naglalagay ng ruta ngunit hindi DNS, o nagtutulak ng DNS server na hindi maabot ng VM, ay gumagawa ng pagkabigo sa paghahanap ng pangalan sa loob ng container habang gumagana ang host dahil may dagdag na resolver o naka-cache na sagot ang host. Iyon ay problemang resolver na nakasuot ng costume ng container. Nakakaligtas ito sa bawat muling pagkonekta ng VPN na sinusubukan mo, dahil dinadala na ng tunnel ang trapikong hiniling mong dalhin nito.

Magkaiba ang pag-overlap ng address at MTU

Dalawang pagbigo ang dapat bigyan ng sariling diagnosis dahil madalas silang napagkakamalang patakaran sa access. Ang una ay pag-overlap ng address: kung nagtutulak ang VPN ng range na bumabangga sa default bridge subnet ng isang container network, ang ruta ng container para sa range na iyon ay tumuturo sa lokal na bridge at hindi kailanman umaabot sa tunnel. Suriin ang aktwal na subnet sa halip na manghula:

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

Ang pangalawa ay problema sa MTU. Kung nagtatatag ang koneksyon at natatapos ang TLS ngunit nag-aantala ang mas malalaking tugon, may problema ka sa laki ng packet, hindi sa awtorisasyon, at hindi kailanman maaayos ito ng pagpapalit ng DNS record. Subukan gamit ang maliit na kahilingan at malaki bago ka magbago ng anuman, at itala ang parehong resulta.

Ang lunas sa overlap ay ibang container subnet o isang saklaw na ruta, na pipiliin ng may-ari ng address plan. Ang lunas sa MTU stall ay pag-clamp o pagbaba ng MTU ng tunnel o interface sa halagang nakakaligtas sa landas, inilalapat sa layer na kontrolado mo.

Ang proxy configuration ay per proseso, hindi per machine

Sa loob ng container, pinapangalanan ng localhost ang sariling network context ng container na iyon, kaya ang proxy na tumatakbo sa host ay hindi maaabot doon sa ilalim ng pangalang iyon. Nagbibigay ang Docker Desktop ng host.docker.internal para sa pag-access sa host, at sa Linux idinadagdag mo ito nang tahasan gamit ang --add-host=host.docker.internal:host-gateway. Sa alinmang paraan, binibigyan ka ng pangalang iyon ng ruta sa host; hindi ito gumagawa ng proxy service o nagbibigay sa iyo ng awtoridad na gamitin ito.

Gamitin ang proxy address at port na ibinigay para sa aktwal na kapaligiran, at suriin kung sino ang nagbabasa nito. Ang mga variable na inilabas sa interactive na shell ay hindi awtomatikong nagko-configure sa bawat editor extension, language server, build tool at background daemon. Ang mahalaga ay ang prosesong gumawa ng nabigong kahilingan, kaya siyasatin ang kapaligiran nito kaysa sa iyong terminal.

Sa huli, hayaan ang lunas na ipaliwanag ang sarili nito. Ang kapaki-pakinabang na resolusyon ay pinapangalanan ang hangganang mali, ang setting na nagbago nito, at ang hanay ng prosesong apektado nito ngayon. Ang muling pag-restart ng VPN, editor at engine nang sunud-sunod ay maaaring magbago ng sintomas, ngunit wala itong iniiwang magagamit ng susunod na tao.