Sut i gyfeirio traffig cynwysyddion Docker yn unig drwy OpenVPN

Nid yw pecyn y cynhwysydd byth yn cyrraedd tun0, ac ni fydd galluoedd ychwanegol ar y cynhwysydd yn newid hynny. Mae dau chwiliad llwybr rhwng y gwestai a'r twnnel: un y tu mewn i ofod enw rhwydwaith y gwestai, un ar y gwesteiwr ar ôl i'r ffrâm lanio ar y bont, ac mae'r ail yn ymgynghori â thabl gwahanol â rheolau cyfateb gwahanol. Fy nghynllun cyfeirio yw gwesteiwr Linux sy'n rhedeg cleient OpenVPN sy'n dal 10.8.0.10 ar tun0, pont Docker ar 172.18.0.0/16, a chyfeiriad preifat na all ond ochr y twnnel ei gyrraedd. Mae'r nod yn aros yn gul: mae'r is-rwydwaith gwestai hwnnw'n gadael drwy'r twnnel tra bo'r gwesteiwr yn cadw ei uplink arferol.

Mae rhedeg y cleient VPN y tu mewn i'r cynhwysydd yn ddyluniad gwahanol, nid yn llwybr byr. Yna mae'r cynhwysydd yn berchen ar ei dwnnel a'i gymwysterau, ac mae'r gwaith yn symud i Dockerfile yn lle aros yn iptables.

Mae anfon yn dewis llwybr yn ôl cyrchfan, yna mae NAT yn ailysgrifennu'r ffynhonnell

Gyda net.ipv4.ip_forward=1 wedi'i osod, mae pecyn a anfonir yn cael ei lwybro yn ôl cyrchfan yn unig, yn y prif dabl. Nid oes rhan i'r ffynhonnell yn y penderfyniad hwnnw. Dim ond ar ôl dewis y llwybr y mae'r cnewyllyn yn rhedeg POSTROUTING, a dyna lle mae rheol Docker ei hun: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE. Mae unrhyw beth sy'n gadael y bont i ryngwyneb arall yn cael ei gyfieithu, ac mae'r cyfeiriad y mae'n dod yn dibynnu ar y rhyngwyneb y gwnaeth y llwybr ei anfon iddo.

Mae'r rheol honno'n esbonio'r rhan fwyaf o'r symptomau y gofynnir i mi amdanynt. Os nad oes gan y prif dabl lwybr ar gyfer y gyrchfan breifat, mae'r pecyn yn gadael drwy'r uplink yn cario cyfeiriad corfforol y gwesteiwr. Mae eich darparwr yn gollwng y gyrchfan, neu mae'r safle pell yn gollwng ffynhonnell RFC 1918 na wnaeth ei disgwyl, ac mae'r cynhwysydd yn rhedeg allan o amser tra bo'r twnnel yn aros i fyny ac yn iach. Nid yw cipiad ar tun0 yn dangos dim, a dyna'r arwydd. Os yw'r llwybr yn pwyntio at tun0, mae MASQUERADE yn ailysgrifennu'r ffynhonnell i 10.8.0.10 ac mae'r un cynhwysydd yn gweithio heb i chi gyffwrdd â dim.

Gofynnwch am y chwiliad sy'n enwi ffynhonnell y gwestai. Heb from a iif mae'r gwesteiwr yn ateb dros ei soced ei hun ac yn adrodd llwybr na fydd y pecyn a anfonir byth yn ei gymryd:

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

Os yw'r ateb hwnnw'n enwi'r uplink, nid yw'r twnnel yn y darlun ac ni fydd unrhyw osodiad ar ochr y twnnel yn helpu.

Trosglwyddwch y gwestai i gyfeiriad ei hun y twnnel

Y newid lleiaf sy'n gweithio yw ailysgrifennu ffynhonnell benodol ar y ffordd allan. Mewnosodwch ef yn lle ei atodi: mae Docker eisoes yn eistedd ar ben POSTROUTING, felly mae rheol a ychwanegir gyda -A yn cael ei gwerthuso y tu ôl i un Docker ac ni fydd byth yn tanio.

iptables -t nat -I POSTROUTING 1 -s 172.18.0.0/16 -o tun0 -j SNAT --to-source 10.8.0.10

Mae dau amod yn penderfynu a fydd hynny'n dal. Rhaid i'r cyfeiriad fod yr un y mae'r cleient yn ei ddal mewn gwirionedd, felly pinwch ef gyda chofnod fesul cleient sy'n cynnwys ifconfig-push 10.8.0.10 255.255.255.0; mae rheol sy'n enwi cyfeiriad na chafodd ei ddyrannu erioed yn cynhyrchu gollyngiadau distaw, nid gwall. Ac mae'n rhaid i'r ochr bell dderbyn y ffynhonnell honno a llwybro atebion yn ôl, a dyna pam mae rhestr ganiatáu yno'n enwi cyfeiriad y twnnel yn hytrach nag is-rwydwaith y gwestai. Pan fo cyfeiriad y cleient yn ddynamig, -j MASQUERADE gyda -o tun0 yn dilyn beth bynnag y mae'r rhyngwyneb yn ei ddal, ar gost polisi pell na allwch ysgrifennu yn ei erbyn â gwerth sefydlog.

Hidlo yw'r hanner arall. Mae Docker yn gosod y polisi FORWARD i drop ac yn fflysio'r cadwyni y mae'n berchen arnynt ar bob ailgychwyn daemon, felly rhowch bolisi lleol yn DOCKER-USER, sy'n goroesi:

iptables -I DOCKER-USER -i br-appnet -o tun0 -j ACCEPT
iptables -I DOCKER-USER -i tun0 -o br-appnet -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Mae'r rheol ddychwelyd yn bwysig: ni dderbynnir ateb sy'n cyrraedd ar tun0 ar gyfer cysylltiad a agorwyd gan y bont dim ond oherwydd bod y cyfeiriad allan wedi bod.

Cadwch y gwesteiwr yn uniongyrchol gyda rheol ffynhonnell

Pan ddylai'r bont gyfan ddefnyddio'r twnnel ond na ddylai dim arall ar y gwesteiwr, heidiwch NAT a rhowch ei dabl ei hun i'r ffynhonnell honno. Mae cyfeiriadau gwestai wedyn yn aros yn weladwy o ben bwy gilydd.

echo "200 vpnbox" >> /etc/iproute2/rt_tables
ip rule add from 172.18.0.0/16 lookup vpnbox pref 1000
ip route add default dev tun0 table vpnbox

Ymgynghorir â rheolau cyn y prif dabl, ac mae from yn cyfateb i'r ffynhonnell. Mae pecynnau allanol y twnnel ei hun yn cario ffynhonnell corfforol y gwesteiwr, felly nid ydynt byth yn cyfateb i from 172.18.0.0/16 ac ni all y twnnel lwybro ei hun yn ôl iddo'i hun. Yr hunan-eithriad hwnnw sy'n gwneud y cynllun yn sefydlog.

Mae llwybr yr ateb nawr angen help. Mae'r ochr bell yn gweld 172.18.0.x heb ei chyfieithu ac nid oes ganddi reswm i wybod ble mae'n byw. Ar y gweinydd, mae angen ffeil fesul cleient iroute 172.18.0.0 255.255.0.0 fel bod tabl mewnol y gweinydd yn trosglwyddo'r rhagddodiad hwnnw i'r cleient hwn, ac route 172.18.0.0 255.255.0.0 wedi'i gwthio fel bod cleientiaid eraill yn gwybod ei fod yn bodoli.

Dau wiriad cyn ymddiried ynddo. Rhedwch ip route show default: gyda redirect-gateway def1 mae'r tabl yn dal 0.0.0.0/1 a 128.0.0.0/1 drwy tun0, ac nid yw'r gwesteiwr yn uniongyrchol o gwbl, oherwydd mae'r hanner-ragosodiadau hynny'n ennill heb ddisodli default. Mae rheolau a ychwanegir gyda ip rule add hefyd yn diflannu ar ailgychwyn, felly cariwch nhw mewn sgript up.

Maint pecyn yw'r methiant rydych chi'n ei gyfarfod yn ail

Mae rhyngwyneb pont ar 1500 beit yn rhoi mwy i'r twnnel nag y gall ei gario unwaith y cedwir y penawdau UDP ac IP allanol. Mae cyfnewidiadau bach yn pasio, felly mae DNS yn datrys ac mae'r cydlawenhau TLS yn gorffen, yna mae uwchlwytho mwy yn hongian heb wall yn unman. Mae'r anfonydd yn dal i ailadrodd yr un maint segment oherwydd nad yw'r neges ICMP am angen darnio, a fyddai'n dweud wrtho am grebachu, byth yn cyrraedd.

Trwsiwch ef yn y rhyngwyneb, yn yr MSS, neu'r ddau. Nid oes angen cydweithrediad y gwestai ar glensio:

ip link set dev tun0 mtu 1400
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Dim ond TCP y mae'r clensio'n ei ailysgrifennu. Mae UDP, QUIC yn gynwysedig, angen gostwng rhyngwyneb y gwestai yn lle hynny, gyda --opt com.docker.network.driver.mtu=1400 wrth greu'r rhwydwaith neu'r allwedd compose gyfatebol.

DNS a'r gwiriadau sy'n werth eu hailadrodd

Mae datrys enwau'n dilyn yr un llwybr. Mae datryswr mewnol Docker yn 127.0.0.11 yn anfon ymlaen i weinyddwyr cyfluniwydig y gwesteiwr, felly mae cynhwysydd yn etifeddu beth bynnag y mae'r gwesteiwr yn ei ddefnyddio. Pan fo'r parth preifat yn cael ei ateb gan ddatryswr y gellir ei gyrraedd drwy'r twnnel yn unig, pwyntiwch y gwestai at y cyfeiriad hwnnw, a phrofwch gyda getent hosts y tu mewn i'r cynhwysydd yn hytrach nag ar y gwesteiwr.

• Rhedwch y cais sy'n methu y tu mewn i'r gwestai; mae prawf ar ochr y gwesteiwr yn defnyddio cyfeiriad ffynhonnell gwahanol ac yn cuddio'r broblem.
• Darllenwch y cyfrifwyr ar y rheolau NAT a hidlo a ychwanegoch. Mae rheol heb unrhyw gyfatebiaeth yn gamgymeriad llwybro, nid camgymeriad polisi.
• Cadarnhewch fod cyfeiriad y twnnel yn eich rheol SNAT yn un y mae'r cleient yn ei ddal mewn gwirionedd.
• Gostyngwch MTU y gwestai neu glensiwch MSS cyn beio'r gweinydd am stondin.

Ewch i lawr y rhestr honno ac arhoswch ar y methiant cyntaf. Yr haen honno sydd i'w thrwsio; nid yw unrhyw beth a ychwanegir ymhellach i lawr ond yn cuddio'r ffin sy'n torri.