Lagaðu Docker- og WSL-umferð sem hunsar VPN hýsisins

Ég eyddi stórum hluta morguns í vor í að elta gám sem gat ekki leyst eitt einasta innra nafn, á meðan vafrinn við hliðina opnaði wiki án kvartana. Tunnellinn var uppi, vafrinn sannaði það, og gámurinn sat í öðru netnafnarými með annarri leiðatöflu og öðrum leysi. Það sem kemur næst er röðin sem ég athuga núna: fyrst leiðatöflur, næst nafnaleysing, þriðja framsending og að lokum hýsilkerfið. Stoppaðu við fyrsta skrefið sem nú þegar bregst, því að bæta reglum neðar í staflanum felur mörkin í stað þess að færa þau.

Berðu saman þrjár leiðatöflurnar áður en þú breytir reglu

Gámur á sjálfgefinni brú Docker hefur eina sjálfgefna leið sem bendir á docker0-hliðið og hefur ekki hugmynd um að tun0 sé til. Hýsillinn hefur tun0, leiðirnar sem VPN ýtti og hugsanlega stefnureglu sem sendir prófumferð út um annað viðmót en þú átt von á. WSL bætir þriðju töflunni við bak við sitt eigið sýndarviðmót. Prentaðu allar þrjár áður en þú breytir einhverri þeirra.

Ef eina leið gámsins er brúin og tun0 birtist aldrei í nafnarými hans, þá hjálpar ekkert hér fyrir neðan: engin nafnaþjónabreyting býr til leið, og engin leið býr til tunnellauðkenni sem jafninginn samþykkir. Röðin skiptir máli því að DNS-bilun og leiðarbilun líta eins út að innanverðu skel.

Beindu leysinum að tunnellinum í stað opinbers

Á hýslinum, resolvectl status listar DNS-þjóna fyrir hverja tengingu, og readlink -f /etc/resolv.conf segir þér hvort skráin sé systemd-stubbur, NetworkManager-skrá eða eitthvað sem biðlarinn frá birgjanum endurskrifaði. Inni í gámi á neti sem notandinn skilgreinir, /etc/resolv.conf nefnir 127.0.0.11, innbyggðan leysi Docker, sem framsendir til þess upstreams sem daemoninn var stilltur með. Gámur á sjálfgefnu brúnni fékk hins vegar afrit af skrá hýsilsins þegar hann var búinn til, og heldur henni.

Það afrit er ástæðan fyrir því að tunnell sem kemur upp eftir að gámurinn byrjar lætur gámurinn spyrja gamla upstreamsins. Annað hvort sendir þú leysi VPN skýrt með docker run --dns 10.8.0.53, eða stillir "dns": ["10.8.0.53"] í /etc/docker/daemon.json og endurræsir daemoninn, eða býrð gámurinn til aftur þegar tunnellinn er uppi. Endursköpun er venjulega ódýrari en að kemba leysi sem var rétt fyrir klukkustund.

Að skipta yfir í opinberan leysi er viðgerðin sem heldur einkenninu. Hann leysir internetið og bregst í öllum einkasvæðum, og hann getur hljóðlega farið fram hjá síuninni sem tunnellinn er til fyrir. Ef þú reynir að skrifa inni í /etc/resolv.conf gáms sem er í gangi, búðu þig við Device or resource busy: Docker bind-mountar þá skrá, svo breytingin þarf fyrst afturtengingu. Að stilla --dns við sköpun er röðin sem lifir endurræsingu.

Framsendu og þýddu þegar gámar fá tunnellinn að láni

Með sjálfgefnu brúnni er hýsillinn beinir milli docker0 og tun0, og sjálfgefið gerir hann hvorki né. Kveiktu á framsendingu og þýddu upprunavistfangið svo jafninginn sjái tunnellvistfang hýsilsins í stað vistfangs sem hann hefur enga afturleið að (skiptu tun0 út fyrir það sem biðlarinn þinn kallar viðmótið):

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i docker0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o docker0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

FORWARD-reglurnar skipta máli á hýslum þar sem framsendingarstefnan er DROP. Docker setur inn eigin keðjur, svo prófaðu með pakka í stað þess að lesa iptables -S: frá gámnum, ip route get 10.8.0.20 ætti að nefna hlið brúarinnar, og nc -vz 10.8.0.20 443 ætti að tengjast eða lenda í tíma á tunnellinum í stað leysisins.

Án MASQUERADE þarf jafninginn afturleið að 172.17.0.0/16, sem flestir fjartengdir VPN-þjónustur ýta ekki. Hér brotnar líka stefnubundinn biðlari áætlunina: ef hann grípur aðeins umferð frá tilteknum UID eða cgroups, sjá framsendingarreglurnar þínar aldrei pakkann inni í tunnellinum, og viðgerðin tilheyrir leiðarstefnu biðlarans en ekki iptables. Reglur sem bætt er við handvirkt hverfa við endurræsingu, svo settu þær í systemd-einingu eða netfilter-persistent-töflu og prófaðu aftur eftir endurræsingu, þar sem tunnell sem kemur upp seint getur skolað þeim burt.

Settu tunnellinn inni í gámnum þegar einangrun er markmiðið

Ef einn gámur þarf að fara út um tiltekinn hnút, keyrðu biðlarann í þeim gámi. Hann þarf --cap-add NET_ADMIN og --device /dev/net/tun, og þá á hann sitt eigið tun0, leiðir og eldvegg. Ef aðrir gámar fara í gegnum hann, þarf hann líka framsendingu og MASQUERADE-reglu inni í gámnum, og þeir jafningar þurfa skýra leið eða proxy sem bendir á hann; sjálfgefna brú Docker bætir ekki þeirri leið við fyrir þig.

Hýsilnet, docker run --network host, er ódýra útgáfan: gámurinn gengur í nafnarými hýsilsins og sér tunnelleiðirnar beint. Það sleppir líka neteinangrun, býður upp á portárekstra og er í reynd Linux-valkostur. Birt port er ekki staðgengill. -p 8080:80 gerir þjónustu aðgengilega frá hýslinum; það gerir innri 10.x vistföng ekki aðgengileg frá innanverðu gámnum, og að rugla þessu tvennu er leiðin sem leiðarvandamál verður opið gagnagrunnsport.

Greindu nafnabilun frá skarastandi undirneti

Sjálfgefin brú Docker er 172.17.0.0/16, og mörg fyrirtækja-VPN-söfn liggja innan 172.16.0.0/12. Þegar tunnellinn á það bil, getur umferð sem ætluð er gámi verið beint inn í tunnellinn í staðinn. Nöfn bregðast, villan lítur út eins og DNS, og vandamálið eru vistföngin. Athugaðu áfangastaðinn, ekki leysinn: ip route get 172.17.0.5 á hýslinum, berðu svo saman forskeyti brúarinnar við VPN-safnið og við docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'.

Viðgerðin er að færa eitt bilanna: annað hvort annað sjálfgefið vistfangasafn fyrir Docker í daemon.json eða annað safn á miðaranum. Að bæta við öðrum nafnaþjóni gerir ekkert hér, og ssh -b ekki heldur: að binda biðlarann við viðmót breytir upprunavistfanginu, ekki áfangaleið sem bendir inn í tunnellinn. Fljótleg verkaskipting: nafn sem leysist á hýslinum en ekki í gámnum er leysivandamál, á meðan bein IP-tenging sem hangir í gámnum en virkar á hýslinum er leiðar- eða framsendingarkeðjuvandamál.

WSL og Docker Desktop fylgja ekki reglum Linux

Í sjálfgefnum NAT-ham sínum situr WSL bak við sitt eigið sýndarviðmót og fær ekki innri leiðir eða DNS-viðskeyti Windows-VPN, sem er ástæðan fyrir því að vafrinn virkar og ping inni í dreifingunni ekki. Speglað net, sem er fáanlegt í nýlegum Windows 11 byggingum, deilir í staðinn viðmótum hýsilsins, en það verður að virkja í .wslconfig og endurræsa dreifinguna með wsl --shutdown. Staðfestu virka haminn með wslinfo --networking-mode áður en þú beitir viðgerð, því að NAT-svarið er rangt fyrir speglaðan ham og öfugt.

Docker Desktop bætir við enn einu lagi. Linux-gámar á Windows sitja bak við NAT-útfærslu sem hefur sögulega heitið vpnkit, og leið þeirra er frábrugðin upprunalegum Linux-hýsli. Windows-gámar tengjast gegnum sýndarrofa Hyper-V, og fyrirtækjabiðlari getur lokað á umferð frá þeim rofa, svo Linux-gámar á sömu vél geta náð netinu á meðan Windows-gámar hafa ekkert. Ytri rofi sem er bundinn við líkamlega millistykkið er venjulega lausnin, og hann breytir netauðkenni gámsins á vegu sem stefnan leyfir kannski ekki.

Áður en þú skrifar aðra reglu, farðu í gegnum fjögur lögin í röð og stoppaðu þar sem eitt þeirra er rangt:

• Inni í gámnum: nær ip route einkaforskeytinu, og nefnir /etc/resolv.conf upstream sem leysir það?
• Á hýslinum: er framsending kveikt, er NAT bundið við tunnellviðmótið, og samþykkir framsendingarkeðjan brú að tunnelli?
• Hjá jafninganum: þekkir hann afturleið, eða treystir þú á NAT til að fela undirnet gámsins?
• Á kerfinu: er WSL í NAT- eða spegluðum ham, og er gámurinn Linux eða Windows?

Keyrðu hverja prófun aftur í ferskum gámi eða skel. Langlífur ferli með skyndiminnið svar eða komna tengingu heldur áfram að bregðast eftir að stillingin er rétt, og sú bilun lítur nákvæmlega út eins og viðgerð sem virkaði ekki.