Dev Container nær ekki hýsli sem aðeins er aðgengilegt í gegnum VPN: hvar á að leita

Einkaaðgangs-API opnast í vafranum á skjáborðinu og mistekst í þróunargámnum. Það er ekki mótsögn, og það er sjaldan VPN-ið sjálft. Beiðni vafrans og beiðnin sem mistekst voru gerðar af mismunandi ferlum, með mismunandi resolverum, proxyum og leiðum, og oft úr gjörólíkum netheimum. „Á fartölvunni minni“ getur átt við Windows hýsilinn, WSL dreifingu, sýndarvél Docker Desktop og gám inni í þeirri VM — fjögur samhengi sem hvert um sig getur svarað sama hýslinafni á mismunandi hátt. Finndu út hvort þeirra ferlið sem mistekst notar áður en þú snertir eina stillingu.

Finndu ferlið áður en þú breytir stillingu

Byrjaðu á gámavélinni, ekki VPN biðlarans. Spurðu hvaða samhengi skipanalínan talar við og á hvaða stýrikerfi sú vél keyrir, því Linux gámur sem skjáborðs-VM stýrir fer aðra leið en sá sem staðbundin daemon stýrir:

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

Í Windows segir wsl -l -v þér hvort dreifingin keyri undir WSL 2, sem setur hana bak við sinn eigin sýndarrofa. Sú smáatriði ræður því hvort gámurinn deilir leiðatöflu hýsilsins eða situr bak við NAT sem þarf framsendan port eða hýsilnafn til að ná hýsilnum.

Haltu einni beiðni stöðugri og berðu saman

Veldu einn meinlausan endapunkt á einkahýsilnum og notaðu hann fyrir hverja samanburð: úr vafranum, úr flugstöð hýsilsins, úr WSL dreifingunni og innan úr gámnum. Skrifaðu niður fjóra hluti fyrir hverja tilraun: leysta heimilisfangið, hvort proxy var notað, flokk mistakans og liðinn tíma. Nafnaleit, tengingarmyndun, TLS staðfesting og HTTP staða eru fjögur mismunandi vandamál, og að blanda þeim í „það virkar ekki“ eyðir morgni.

Keyrðu samanburðinn inni í gámnum sem mistekst, með tímamörkum svo hljóðlát eldveggur haldi flugstöðinni ekki mínútum saman. Nýr gámur endurgerir netsamhengi vélarinnar en ekki nafnrými, proxy breytur eða resolver forritsgámsins, svo docker exec inn í raunverulega gáminn er hið gildandi próf, og hliðargámur er aðeins leið til að einangra hvort munurinn sé í vélinni eða gámnum:

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 grunnmyndin ber busybox og engan curl, og það er einmitt slík smáatriði sem láta afritaða greiningarblokk mistakast: veldu mynd með biðlaranum, eða bættu honum við í sama keyrslu. Samanburður við ótengdar opinberar síður einangrar ekkert. Ef https://example.com virkar úr gámnum hefur þú lært að gámurinn hefur internetaðgang, og ekkert um hvort hann nái einkaaðgangi í gegnum göngin. Á sama hátt sannar opnun nýrrar flugstöðvar aðeins að nýja flugstöðin virki, ekki að hún deili keyrsluumhverfi með forritinu sem mistókst.

Docker Desktop getur virkað með VPN

Eigin skjöl Docker um VPN og hýsiltengingu lýsa þessu sem studdu uppsetningu, og heiðarleg samantekt er að það virkar frekar en að vera sjálfkrafa bilað. Ekki gera ráð fyrir að skjáborðs-VM-in fari fram hjá göngum hýsilsins af hönnun; í mörgum uppsetningum fylgir umferðin göngum hýsilsins rétt, og þess vegna framleiðir þjóðsagan „Docker hunsar VPN-ið“ örugg og röng ráð.

Það sem enn skiptir máli er bakendinn sem er notaður, split-tunnel stefna biðlarans og resolver stillingin sem VM-in fékk. VPN biðlari sem setur upp leiðir en ekki DNS, eða ýtir DNS þjóni sem VM-in nær ekki, framleiðir nafnaleitarbilun inni í gámnum á meðan hýsillinn virkar því hann hefur auka resolver eða skyndiminnisvarð svar. Það er resolver vandamál í gámabúningi. Það lifir af hverja VPN endurtengingu sem þú prófar, því göngin bera þegar umferðina sem þú baðst um að bera.

Heimilisfangaskörun og MTU eru mismunandi bilanir

Tvær bilanir eiga skilið eigin greiningu því oft er ruglað saman við aðgangsstefnu. Sú fyrsta er heimilisfangaskörun: ef VPN-ið ýtir sviði sem rekst á sjálfgefna brúarundirnet gámanets, þá bendir leið gámsins fyrir það svið á staðbundna brúna og nær aldrei göngunum. Skoðaðu raunverulegu undirnetin í stað þess að giska:

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

Sú seinni er MTU vandamál. Ef tenging myndast og TLS klárast en stærri svör stöðvast, hefur þú pakkastærðarvandamál, ekki heimildarvandamál, og að skipta um DNS færslur mun aldrei laga það. Prófaðu með lítilli og stórri beiðni áður en þú breytir einhverju, og skráðu bæði úrslitin.

Lausnin á skörun er annað gámaundirnet eða takmörkuð leið, valin af þeim sem á heimilisfangaáætlunina. Lausnin á MTU stöðvun er að þrengja eða lækka MTU ganganna eða viðmótsins í gildi sem lifir leiðina, beitt á laginu sem þú stjórnar.

Proxy stilling er fyrir hvert ferli, ekki hverja vél

Inni í gám nafngreinir localhost eigið netsamhengi þess gáms, svo proxy sem keyrir á hýsilnum er ekki aðgengilegt þar undir því nafni. Docker Desktop veitir host.docker.internal fyrir hýsilaðgang, og í Linux bætirðu því skýrt við með --add-host=host.docker.internal:host-gateway. Hvort sem er, þá gefur það nafn þér leið að hýsilnum; það býr ekki til proxy þjónustu og heimilar þér ekki að nota eina.

Notaðu proxy heimilisfangið og portið sem eru gefin fyrir raunverulega umhverfið, og athugaðu hver les þau. Breytur sem eru fluttar út í gagnvirkri skel stilla ekki sjálfkrafa hverja ritstjóraviðbót, tungumálaþjón, byggingartól og bakgrunnsdaemon. Það sem skiptir máli er ferlið sem gerði beiðnina sem mistókst, svo skoðaðu umhverfi þess en ekki flugstöðvarinnar þinnar.

Að lokum, láttu viðgerðina útskýra sig sjálfa. Nýtileg lausn nefnir landamærin sem voru röng, stillinguna sem breytti þeim og safn ferla sem hún hefur nú áhrif á. Endurræsing VPN-sins, ritstjórannar og vélarinnar í röð getur breytt einkennunum, en skilur ekkert eftir sem næsta manneskja getur notað.