Pakki gámsins nær aldrei til tun0 og viðbótarmöguleikar á gámnum breyta því ekki. Milli gests og ganganna eru tvær slóðaleitir: ein inni í nafnrými netkerfis gestsins, ein á hýsilnum eftir að ramminn lendir á brúnni, og hin spyr aðra töflu með öðrum samsvörunarreglum. Uppsetning mín er Linux-hýsill sem keyrir OpenVPN biðlara sem heldur 10.8.0.10 á tun0, Docker-brú á 172.18.0.0/16, og einkaaðsetri sem aðeins hlið ganganna nær í. Markmiðið helst þröngt: það gestaundirnet fer út um göngin á meðan hýsillinn heldur venjulegu uplinki sínu.

Að keyra VPN-biðlarann inni í gámnum er önnur hönnun, ekki flýtileið. Þá á gámurinn sitt eigið göng og sín skilríki, og vinnan flyst í Dockerfile í stað þess að vera í iptables.

Framsending velur slóð eftir áfangastað, svo endurskrifar NAT upprunann

Þegar net.ipv4.ip_forward=1 er stillt, er framsendri pakkanum beint aðeins eftir áfangastað, í aðaltöflunni. Uppruninn gegnir engu hlutverki í þeirri ákvörðun. Aðeins eftir að slóðin er valin keyrir kjarninn POSTROUTING, og þar liggur eigin regla Docker: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE. Allt sem fer af brúnni til annars viðmóts er þýtt, og heimilisfangið sem það verður fer eftir viðmótinu sem slóðin sendi það á.

Þessi regla skýrir flest einkennin sem ég er spurður um. Ef aðaltaflan hefur enga slóð fyrir einkaaðfangastaðinn fer pakkinn út um uplinkið með líkamlegt heimilisfang hýsilsins. Þjónustuveitandinn þinn hendir áfangastaðnum, eða fjarlægi vefurinn hendir uppruna RFC 1918 sem hann bjóst aldrei við, og gámurinn rennur út á tíma á meðan göngin standa og eru heilbrigð. Upptaka á tun0 sýnir ekkert, og það er vísbendingin. Ef slóðin bendir raunverulega á tun0, endurskrifar MASQUERADE upprunann í 10.8.0.10 og sami gámur virkar án þess að þú snertir neitt.

Biddu um leitina sem nefnir uppruna gestsins. Án from og iif svarar hýsillinn fyrir eigin sokk og tilkynnir braut sem framsendi pakkinn mun aldrei fara:

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

Ef það svar nefnir uplinkið eru göngin ekki í myndinni og engin stilling á hlið ganganna hjálpar.

Færðu gestinn á eigið heimilisfang ganganna

Minnsta breytingin sem virkar er skýr endurskrifun upprunans á útleið. Setjið hana inn í stað þess að bæta henni við: Docker situr þegar á oddi POSTROUTING, svo regla sem bætt er við með -A er metin á bak við reglu Docker og kviknar aldrei.

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

Tvö skilyrði ráða því hvort þetta haldist. Heimilisfangið verður að vera það sem biðlarinn hefur raunverulega, svo festu það með færslu fyrir hvern biðlara sem inniheldur ifconfig-push 10.8.0.10 255.255.255.0; regla sem nefnir heimilisfang sem aldrei var úthlutað framkallar hljóðlátan brottfall, ekki villu. Og fjarlæga hliðin verður að samþykkja þennan uppruna og beina svörum til baka, þess vegna nefnir leyfislistinn þar heimilisfang ganganna en ekki gestaundirnetið. Þegar heimilisfang biðlarans er kvikt, -j MASQUERADE með -o tun0 fylgir því sem viðmótið hefur, á kostnað fjarlægrar stefnu sem þú getur ekki skrifað fast gildi gegn.

Síun er hinn helmingurinn. Docker setur stefnuna FORWARD á drop og hreinsar keðjurnar sem það á við hverja endurræsingu þjóns, svo settu staðbundna stefnu í DOCKER-USER, sem lifir:

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

Endurkastsreglan skiptir máli: svar sem berst á tun0 fyrir tengingu sem brúin opnaði er ekki samþykkt bara vegna þess að útleiðin var það.

Haltu hýsilnum beinum með upprunareglu

Þegar öll brúin á að nota göngin en ekkert annað á hýsilnum, slepptu NAT og gefðu þeim uppruna sína eigin töflu. Gestaheimilisföng eru þá sýnileg frá enda til enda.

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

Reglur eru skoðaðar fyrir aðaltöfluna, og from passar við upprunann. Ytri pakkar ganganna sjálfra bera líkamlegan uppruna hýsilsins, svo þeir passa aldrei við from 172.18.0.0/16 og göngin geta ekki beint sér aftur inn í sig. Þessi sjálfsútilokun er það sem gerir uppsetninguna stöðuga.

Endurleiðin þarf nú hjálp. Fjarlæga hliðin sér óþýtt 172.18.0.x og hefur enga ástæðu til að vita hvar það býr. Á þjóninum þarf skrá fyrir hvern biðlara iroute 172.18.0.0 255.255.0.0 svo að innri tafla þjónsins afhendi þetta forskeyti þessum biðlara, og ýtt route 172.18.0.0 255.255.0.0 svo að aðrir biðlarar viti að það er til.

Tvær prófanir áður en þú treystir því. Keyrðu ip route show default: með redirect-gateway def1 heldur taflan 0.0.0.0/1 og 128.0.0.0/1 um tun0, og hýsillinn er alls ekki beinn, því þessar hálf-sjálfgefnar slóðir vinna án þess að skipta um default. Reglur sem bætt er við með ip rule add hverfa líka við endurræsingu, svo hafðu þær í up-skrifu.

Pakkastærð er önnur bilunin sem þú mætir

Brúarviðmót á 1500 bætum gefur göngunum meira en þau þola þegar ytri UDP- og IP-hausarnir bætast við. Litlar skiptingar fara í gegn, svo DNS leysist og TLS-handabandið klárast, síðan hangir stærri upphleðsla án nokkurrar villu hvar sem er. Sendandinn endurtekur sömu sundurgerðarstærð því ICMP-skilaboðin um þörf á sundurliðun, sem myndu segja honum að minnka, koma aldrei.

Lagaðu það á viðmótinu, á MSS eða báðum. Klemmgingin þarf enga samvinnu gestsins:

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

Klemmingin endurskrifar aðeins TCP. UDP, þar á meðal QUIC, þarf í staðinn lægra gestaviðmót, með --opt com.docker.network.driver.mtu=1400 við stofnun netkerfis eða samsvarandi compose-lykli.

DNS og prófanirnar sem eru þess virði að endurtaka

Nafnaleysing fylgir sömu braut. Innbyggði leysir Docker á 127.0.0.11 sendir áfram til stilltra þjóna hýsilsins, svo gámur erfir það sem hýsillinn notar. Þegar einkasvæðinu er svarað aðeins af leysi sem næst um göngin, beindu gestinum á það heimilisfang, og prófaðu með getent hosts inni í gámnum en ekki á hýsilnum.

  • Keyrðu misheppnuðu beiðnina inni í gestinum; prófun á hlið hýsilsins notar annað upprunahandir og felur vandamálið.
  • Lestu teljarana á NAT- og síureglunum sem þú bættir við. Regla án nokkurs samræmis er villa í beiningu, ekki stefnuvilla.
  • Staðfestu að heimilisfang ganganna í SNAT-reglunni þinni sé það sem biðlarinn hefur raunverulega.
  • Lækkaðu MTU gestsins eða klemdu MSS áður en þú kennir þjóninum um stöðvun.

Farðu niður listann og stoppaðu við fyrstu bilun. Það lag er það sem þarf að laga; allt sem bætt er við neðar felur bara mörkin sem brotna.

Tengdir greinar