Nola bideratu Docker edukiontzien trafikoa soilik OpenVPN bidez

Utzi ostalaria bere uplink ohikoan eta jarri edukiontzi azpisare bat tunelean: NAT ordena, iturburu arauak, OpenVPN iroute eta MSS egiaztapenak.

Edukiontziaren paketea ez da inoiz iristen tun0 ra, eta edukiontzian gaitasun gehigarriek ez dute hori aldatuko. Gonbidatuaren eta tunelearen artean bi ibilbide bilaketa daude: bat gonbidatuaren sare-izen espazioaren barruan, bat ostalarian markoa zubira iritsi ondoren, eta bigarrenak beste bat-etortze arau batzuk dituen beste taula bat galdetzen du. Nire erreferentziazko diseinua Linux ostalari bat da, eta bertan OpenVPN bezeroa dabil, honek 10.8.0.10 helbidea tun0-n mantentzen du, Docker zubia 172.18.0.0/16-n, eta tuneleko aldeak soilik iristeko moduko helbide pribatu bat. Helburua estu jarraitzen du: gonbidatu azpisare hori tuneletik irteten da ostalariak bere uplink ohikoa mantentzen duen bitartean.

VPN bezeroa edukiontziaren barruan exekutatzea beste diseinu bat da, ez lasterbide bat. Orduan edukiontziak bere tunela eta bere kredentzialak ditu, eta lana iptables-en geratu beharrean Dockerfile-ra pasatzen da.

Birbidalketak ibilbidea helmugaren arabera aukeratzen du, gero NAT-k iturburua berridazten du

Bertan net.ipv4.ip_forward=1 ezarrita, birbidalitako paketea helmugaren arabera soilik bideratzen da, taula nagusian. Iturburuak ez du erabaki horretan paperik. Ibilbidea aukeratu ondoren soilik exekutatzen du kernelak POSTROUTING, eta hantxe dago Docker-en beraren araua: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE. Zubia beste interfaze baterantz uzten duen guztia itzultzen da, eta bihurtzen den helbidea ibilbideak bidali zuen interfazearen araberakoa da.

Arau horrek galdetzen didateten sintoma gehienak azaltzen ditu. Taula nagusiak helmuga pribaturako ibilbiderik ez badu, paketea uplink-etik irteten da ostalariaren helbide fisikoarekin. Zure hornitzaileak helmuga botatzen du, edo urruneko guneak espero ez zuen RFC 1918 iturburu bat botatzen du, eta edukiontziak denbora gainditzen du tunelea zutik eta osasuntsu dagoen bitartean. Harrapaketa tun0-n ez du ezer erakusten, eta hori da seinalea. Ibilbideak tun0-ra benetan seinalatzen badu, MASQUERADE-k iturburua 10.8.0.10-ra berridazten du, eta edukiontzi berak zuk ezer ukitu gabe funtzionatzen du.

Eskatu gonbidatuaren iturburua izendatzen duen bilaketa. Gabe from eta iif ostalariak bere socketaren alde erantzuten du eta birbidalitako paketeak inoiz hartuko ez duen bide bat jakinarazten du:

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

Erantzun horrek uplink-a izendatzen badu, tunelea ez dago irudian eta tuneleko aldeko ezarpen batek ere ez du lagunduko.

Eraman gonbidatua tunelearen beraren helbidera

Funtzionatzen duen aldaketarik txikiena irteeran iturburuaren berridazketa esplizitua da. Txertatu, ez erantsi: Docker jada POSTROUTING-ren buruan eserita dago, beraz -A-rekin gehitutako araua Docker-enaren atzetik ebaluatzen da eta inoiz ez da pizten.

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

Bi baldintzaren araberakoa da hau mantentzea. Helbidea bezeroak benetan duena izan behar da, beraz lotu bezero bakoitzeko ifconfig-push 10.8.0.10 255.255.255.0 duen erregistro batekin; inoiz esleitu ez zen helbide bat izendatzen duen arauak isilako jaregiteak eragiten ditu, ez errorea. Eta urruneko aldeak iturburu hori onartu eta erantzunak atzera bideratu behar ditu, horregatik hango baimen-zerrendak tunelearen helbidea izendatzen du, ez gonbidatu azpisarea. Bezeroaren helbidea dinamikoa denean, -j MASQUERADE-rekin -o tun0 interfazeak duena jarraitzen du, balio finko baten aurka idatz ezin duzun urruneko politika baten truke.

Iragazketa dagoen beste erdia. Docker-ek FORWARD politika drop-era jartzen du eta daemonaren berrabiarazte bakoitzean bere kateak husten ditu, beraz jarri tokiko politika DOCKER-USER-n, bizirik irauten duena:

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

Itzulerako arauak garrantzia du: tun0-ra iristen den erantzuna zubiak irekitako konexiorako ez da onartzen irteerako norabidea onartu zelako soilik.

Eduki ostalaria zuzen iturburu arau batekin

Zubi osoak tunelea erabili behar duenean baina ostalarian beste ezerk ez, saltatu NAT eta eman iturburu horri bere taula. Gonbidatu helbideak orduan hasieratik amaierara ikusgai geratzen dira.

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

Arauak taula nagusiaren aurretik kontsultatzen dira, eta from iturburuarekin bat dator. Tunelearen beraren kanpoko paketeek ostalariaren iturburu fisikoa daramate, beraz inoiz ez datoz bat from 172.18.0.0/16-rekin, eta tunelea ezin da bere burura atzera bideratu. Auto-bazterketa horrek egiten du diseinua egonkor.

Itzulerako bideak laguntza behar du orain. Urruneko aldeak 172.18.0.x itzuli gabeko bat ikusten du eta ez du arrazoirik jakiteko non bizi den. Zerbitzarian, bezero bakoitzeko fitxategi batek iroute 172.18.0.0 255.255.0.0 behar du, zerbitzariaren barne-taulak aurrizki hori bezero honi eman diezaion, eta bultzatutako route 172.18.0.0 255.255.0.0 behar du, beste bezeroek badakitela existitzen den.

Bi egiaztapen fidatu aurretik. Exekutatu ip route show default : redirect-gateway def1-rekin taulak 0.0.0.0/1 eta 128.0.0.0/1 ditu tun0-ren bidez, eta ostalaria ez da batere zuzena, erdi-default horiek default ordeztu gabe irabazten dutelako. ip rule add-rekin gehitutako arauak ere desagertzen dira berrabiaraztean, beraz eraman itzazu up script batean.

Paketearen tamaina da aurkituko duzun bigarren hutsegitea

1500 byteko zubi interfaze batek tuneleari eramaten duen baino gehiago ematen dio kanpoko UDP eta IP goiburuak gehitzean. Truke txikiak igarotzen dira, beraz DNS ebazten da eta TLS eskuko keinuak amaitzen du, gero karga handiago bat zintzilik geratzen da inon errore barik. Bidaltzaileak segmentu tamaina berari eusten dio, txikitzeko esango liokeen ICMP zatiketa-beharraren mezua inoiz iristen ez delako.

Konpondu interfazean, MSS-n edo bietan. Klemak ez du gonbidatuaren lankidetzarik behar:

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

Klemak TCP baino ez du berridazten. UDP-ak, QUIC barne, gonbidatuaren interfaze beheragoko bat behar du horren ordez, --opt com.docker.network.driver.mtu=1400-rekin sarearen sorreran edo dagokion compose gakoarekin.

DNS eta errepikatzea merezi duten egiaztapenak

Izenen ebazpenak bide bera jarraitzen du. Docker-en resolver integratuak 127.0.0.11-n ostalariaren zerbitzari konfiguratuei pasatzen die, beraz edukiontziak ostalariak erabiltzen duena heredatzen du. Zona pribatuari tuneletik soilik iristeko moduko resolver batek erantzuten dionean, zuzendu gonbidatua helbide horretara, eta probatu getent hosts-rekin edukiontziaren barruan, ez ostalarian.

  • Exekutatu huts egiten duen eskaera gonbidatuaren barruan; ostalari aldeko probak beste iturburu helbide bat erabiltzen du eta arazoa ezkutatzen du.
  • Irakurri gehitu dituzun NAT eta iragazki arauen kontagailuak. Bat-etortzerik gabeko araua bideratze errorea da, ez politika errorea.
  • Egiaztatu zure SNAT arauko tuneleko helbidea bezeroak benetan duena dela.
  • Jaitsi gonbidatuaren MTU edo klema itzazu MSS, zerbitzaria geldotzeagatik errudun egin aurretik.

Joan zerrendan behera eta gelditu lehen hutsegitean. Geruza hori da konpondu beharrekoa; beherago gehitzen den edozerk hausten ari den muga ezkutatzen du soilik.

Erlazionatutako artikuluak