Trwsiwch draffig Docker a WSL sy'n anwybyddu VPN y gwesteiwr

Treuliais y rhan fwyaf o fore y gwanwyn hwn yn erlid cynhwysydd na allai ddatrys un enw mewnol, tra oedd y porwr wrth ei ochr yn agor y wici heb gŵyn. Roedd y twnnel i fyny, roedd y porwr yn profi hynny, ac roedd y cynhwysydd yn eistedd mewn gofod enw rhwydwaith gwahanol gyda thabl llwybrau gwahanol a datryswr gwahanol. Yr hyn sy'n dilyn yw'r drefn yr wyf yn ei gwirio nawr: tablau llwybrau yn gyntaf, datrysiad yn ail, anfon yn drydydd, a llwyfan y gwesteiwr yn olaf. Stopiwch ar y cam cyntaf sy'n methu'n barod, oherwydd mae ychwanegu rheolau ymhellach i lawr y stac yn cuddio'r ffin yn lle ei symud.

Cymharwch y tair tabl llwybrau cyn i chi newid rheol

Mae gan gynhwysydd ar bont ragosodedig Docker un llwybr rhagosodedig sy'n pwyntio at giât docker0, a dim syniad bod tun0 yn bodoli. Mae gan y gwesteiwr tun0, y llwybrau a wthiodd y VPN, ac o bosibl reol polisi sy'n anfon traffig prawf allan trwy ryngwyneb gwahanol i'r un rydych yn ei ddisgwyl. Mae WSL yn ychwanegu trydydd tabl y tu ôl i'w addasydd rhithwir ei hun. Argraffwch y tair cyn golygu unrhyw un ohonynt.

Os mai'r bont yw unig lwybr y cynhwysydd ac nad yw tun0 byth yn ymddangos yn ei ofod enw, ni fydd dim isod yn helpu: nid oes unrhyw newid gweinydd enw yn creu llwybr, ac nid oes unrhyw lwybr yn creu hunaniaeth twnnel y bydd y cymar yn ei derbyn. Mae trefn yn bwysig oherwydd bod methiant DNS a methiant llwybr yn edrych yn union yr un fath o du mewn cragen.

Pwyntiwch y datryswr at y twnnel yn lle un cyhoeddus

Ar y gwesteiwr, resolvectl status yn rhestru gweinyddion DNS fesul cyswllt, a readlink -f /etc/resolv.conf yn dweud wrthych a yw'r ffeil yn stub systemd, yn ffeil NetworkManager, neu'n rhywbeth a ailysgrifennwyd gan gleient gwerthwr. Y tu mewn i gynhwysydd ar rwydwaith a ddiffinnir gan y defnyddiwr, /etc/resolv.conf yn enwi 127.0.0.11, datryswr mewnol Docker, sy'n anfon ymlaen i ba bynnag upstream y cafodd y daemon ei ffurfweddu ag ef. Yn lle hynny, cafodd cynhwysydd ar y bont ragosodedig gopi o ffeil y gwesteiwr pan gafodd ei greu, ac mae'n ei chadw.

Y copi hwnnw yw'r rheswm y mae twnnel sy'n codi ar ôl i'r cynhwysydd ddechrau yn gadael y cynhwysydd yn holi'r hen upstream. Naill ai trosglwyddwch ddatryswr y VPN yn benodol gyda docker run --dns 10.8.0.53, neu gosodwch "dns": ["10.8.0.53"] yn /etc/docker/daemon.json ac ailgychwynnwch y daemon, neu ail-grëwch y cynhwysydd unwaith y bydd y twnnel i fyny. Mae ail-greu fel arfer yn rhatach na dadfygio datryswr a oedd yn gywir awr yn ôl.

Cyfnewid i ddatryswr cyhoeddus yw'r atgyweiriad sy'n cadw'r symptom. Mae'n datrys y rhyngrwyd ac yn methu ym mhob parth preifat, a gall fynd heibio'n dawel i'r hidlo y mae'r twnnel yn bodoli i'w orfodi. Os ceisiwch ysgrifennu y tu mewn i /etc/resolv.conf cynhwysydd sy'n rhedeg, disgwyliwch Device or resource busy: mae Docker yn bind-mowntio'r ffeil honno, felly mae angen dadfowntio yn gyntaf ar y golygiad. Mae gosod --dns wrth greu yn y dilyniant sy'n goroesi ailgychwyn.

Anfonwch ymlaen a chyfieithu pan fydd cynwysyddion yn benthyg y twnnel

Gyda'r bont ragosodedig, mae'r gwesteiwr yn llwybrydd rhwng docker0 a tun0, ac yn ôl y rhagosodiad nid yw'n gwneud y naill na'r llall o'r gwaith. Trowch anfon ymlaen a chyfieithwch y cyfeiriad ffynhonnell fel bod y cymar yn gweld cyfeiriad twnnel y gwesteiwr yn lle un nad oes ganddo lwybr yn ôl iddo (disodlwch tun0 ag enw eich cleient ar y rhyngwyneb):

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

Mae rheolau FORWARD yn bwysig ar westeiwr y mae eu polisi anfon yn DROP. Mae Docker yn mewnosod ei gadwyni ei hun, felly profwch gyda phecyn yn lle darllen iptables -S: o'r cynhwysydd, ip route get 10.8.0.20 dylai enwi giât y bont, a nc -vz 10.8.0.20 443 dylai gysylltu neu amseru allan wrth y twnnel yn lle wrth y datryswr.

Heb MASQUERADE mae'r cymar angen llwybr yn ôl i 172.17.0.0/16, na fydd y rhan fwyaf o VPNau mynediad o bell yn ei wthio. Dyma hefyd lle mae cleient sy'n seiliedig ar bolisi yn torri'r cynllun: os mai dim ond traffig o UIDau neu cgroups penodol y mae'n ei ddal, ni fydd eich rheolau anfon byth yn gweld y pecyn y tu mewn i'r twnnel, ac mae'r atgyweiriad yn perthyn i bolisi llwybro'r cleient yn hytrach nag i iptables. Mae rheolau a ychwanegwyd â llaw yn diflannu ar ailgychwyn, felly rhowch nhw mewn uned systemd neu dabl netfilter-persistent a phrofwch eto ar ôl ailgychwyn, oherwydd gall twnnel sy'n codi'n hwyr eu hysgubo ymaith.

Rhowch y twnnel y tu mewn i'r cynhwysydd pan mai ynysu yw'r nod

Os oes rhaid i un cynhwysydd fynd allan trwy nod penodol, rhedwch y cleient yn y cynhwysydd hwnnw. Mae angen --cap-add NET_ADMIN ac --device /dev/net/tun arno, ac yna mae'n berchen ar ei dun0, ei lwybrau a'i wal dân ei hun. Os yw cynwysyddion eraill yn mynd trwyddo, mae angen anfon a rheol MASQUERADE y tu mewn i'r cynhwysydd arno hefyd, ac mae angen llwybr neu brocsi penodol sy'n pwyntio ato ar y cymariaid hynny; nid yw pont ragosodedig Docker yn ychwanegu'r llwybr hwnnw drosoch.

Rhwydweithio gwesteiwr, docker run --network host, yw'r fersiwn rhad: mae'r cynhwysydd yn ymuno â gofod enw'r gwesteiwr ac yn gweld llwybrau'r twnnel yn uniongyrchol. Mae hefyd yn gollwng ynysu rhwydwaith, yn gwahodd gwrthdrawiadau porth, ac yn ymarferol yn opsiwn Linux. Nid yw porth cyhoeddedig yn gyfnewid. -p 8080:80 yn gwneud gwasanaeth yn gyrraeddadwy o'r gwesteiwr; nid yw'n gwneud cyfeiriadau mewnol 10.x yn gyrraeddadwy o du mewn y cynhwysydd, a chymysgu'r ddau yw sut mae problem llwybro yn troi'n borth cronfa ddata agored.

Gwahaniaethwch fethiant enw oddi wrth is-rwydwaith sy'n gorgyffwrdd

Pont ragosodedig Docker yw 172.17.0.0/16, ac mae llawer o byllau VPN corfforaethol yn gorwedd y tu mewn i 172.16.0.0/12. Unwaith y bydd y twnnel yn berchen ar yr ystod honno, gellir llwybro traffig a fwriadwyd ar gyfer cynhwysydd i'r twnnel yn lle hynny. Mae enwau'n methu, mae'r gwall yn edrych fel DNS, a'r cyfeiriadau yw'r broblem. Gwiriwch y cyrchfan, nid y datryswr: ip route get 172.17.0.5 ar y gwesteiwr, yna cymharwch ragddodiad y bont â phwll y VPN a chyda docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'.

Yr atgyweiriad yw symud un o'r ystodau: naill ai pwll cyfeiriadau rhagosodedig gwahanol i Docker yn daemon.json neu bwll gwahanol ar y canolbwyntydd. Nid yw ychwanegu gweinydd enw arall yn gwneud dim yma, ac nid yw ssh -b chwaith: mae clymu'r cleient i ryngwyneb yn newid y cyfeiriad ffynhonnell, nid llwybr cyrchfan sy'n pwyntio i mewn i'r twnnel. Rhannu gwaith cyflym: enw sy'n datrys ar y gwesteiwr ond nid yn y cynhwysydd yw problem datryswr, tra bod cysylltiad IP uniongyrchol sy'n hongian yn y cynhwysydd ond yn gweithio ar y gwesteiwr yn broblem llwybr neu gadwyn anfon.

Nid yw WSL a Docker Desktop yn dilyn rheolau Linux

Yn ei fodd NAT rhagosodedig, mae WSL y tu ôl i'w addasydd rhithwir ei hun ac nid yw'n derbyn llwybrau mewnol na suffixau DNS VPN Windows, a dyna pam mae'r porwr yn gweithio a ping y tu mewn i'r dosbarthiad yn methu. Mae rhwydweithio drych, ar gael mewn adeilediadau Windows 11 diweddar, yn rhannu rhyngwynebau'r gwesteiwr yn lle hynny, ond rhaid ei alluogi yn .wslconfig ac ailgychwyn y dosbarthiad gyda wsl --shutdown. Cadarnhewch y modd actif gyda wslinfo --networking-mode cyn cymhwyso atgyweiriad, oherwydd mae ateb NAT yn anghywir ar gyfer modd drych ac i'r gwrthwyneb.

Mae Docker Desktop yn ychwanegu haen arall. Mae cynwysyddion Linux ar Windows y tu ôl i weithrediad NAT a elwir yn hanesyddol yn vpnkit, ac mae eu llwybr yn wahanol i westeiwr Linux brodorol. Mae cynwysyddion Windows yn cysylltu trwy swits rhithwir Hyper-V, a gall cleient corfforaethol rwystro traffig o'r swits hwnnw, felly gall cynwysyddion Linux ar yr un peiriant gyrraedd y rhwydwaith tra nad oes gan gynwysyddion Windows ddim. Swits allanol wedi'i rwymo i'r addasydd corfforol yw'r ateb arferol, ac mae'n newid hunaniaeth rwydwaith y cynhwysydd mewn ffyrdd na fydd polisi efallai yn caniatáu.

Cyn i chi ysgrifennu rheol arall, cerddwch y pedair haen yn eu trefn a stopiwch lle mae un ohonynt yn anghywir:

• Y tu mewn i'r cynhwysydd: a yw ip route yn cyrraedd y rhagddodiad preifat, ac a yw /etc/resolv.conf yn enwi upstream sy'n ei ddatrys?
• Ar y gwesteiwr: a yw anfon ymlaen ymlaen, a yw NAT wedi'i rwymo i ryngwyneb y twnnel, ac a yw'r gadwyn anfon yn derbyn pont i dwnnel?
• Ar y cymar: a yw'n gwybod llwybr yn ôl, neu a ydych yn dibynnu ar NAT i guddio is-rwydwaith y cynhwysydd?
• Ar y llwyfan: a yw WSL ym modd NAT neu ddrych, ac a yw'r cynhwysydd yn Linux neu Windows?

Ailredwch bob prawf mewn cynhwysydd neu gragen newydd. Bydd proses hirhoedlog ag ateb wedi'i storio neu gysylltiad sefydledig yn parhau i fethu ar ôl i'r ffurfweddiad fod yn gywir, ac mae'r methiant hwnnw'n edrych yn union fel atgyweiriad na weithiodd.