D'Pak vum Container erreecht ni tun0 an zousätzlech Fäegkeeten um Container änneren dat net. Tëschent dem Gaascht an dem Tunnel stinn zwou Routen-Sich: eng bannent dem Gaascht sengem Netzwierk-Namensraum, eng um Host nodeems de Frame um Bréck landt, an déi zweet froen eng aner Tabell mat aneren Uschlossregelen. Meng Referenz-Anlag ass en Linux-Host deen OpenVPN Client lafe léisst, deen 10.8.0.10 op tun0 hält, eng Docker-Bréck op 172.18.0.0/16, an eng privat Adress déi nëmmen d'Tunnel-Säit erreeche kann. D'Zil bleift schmuel: dee Gaascht-Subnetz geet duerch den Tunnel eraus während den Host säin normale Uplink behält.

Den VPN-Client am Container lafe loossen ass en anert Design, keen Ofkierzung. Dann besëtzt den Container säin Tunnel a seng Umeldungsdaten, an d'Aarbecht geet an en Dockerfile amplaz an iptables ze bleiwen.

D'Weiderleedung wielt eng Route no Destinatioun, duerno schreift NAT d'Quell ëm

Wann net.ipv4.ip_forward=1 gesat ass, gëtt e weidergeleete Pak nëmmen no Destinatioun an der Haapttabell geroutet. D'Quell spillt keng Roll an där Entscheedung. Eréischt nodeems d'Route gewielt ass, féiert de Kernel POSTROUTING aus, an do sëtzt dem Docker seng eege Regel: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE. Alles wat d'Bréck verléisst Richtung eng aner Interface gëtt iwwersat, an d'Adress déi et gëtt hänkt vun der Interface of op déi d'Route et geschéckt huet.

Dës Regel erkläert déi meescht Symptomer déi een mir stellt. Wann d'Haapttabell keng Route fir d'privat Destinatioun huet, verléisst d'Pak den Uplink mat der physescher Adress vum Host. Ären Provider verwërft d'Destinatioun, oder d'Géigendeel verwërft eng RFC 1918 Quell déi et ni erwaart huet, an den Container leeft an en Timeout während den Tunnel uewen a gesond bleift. Eng Opnam op tun0 weist näischt, an dat ass den Zeechen. Wann d'Route wierklech op tun0 weist, schreift MASQUERADE d'Quell op 10.8.0.10 ëm, an dee selwechte Container funktionéiert ouni datt Dir eppes beréiert.

Frot no der Sich déi d'Quell vum Gaascht nennt. Ouni from an iif äntwert den Host fir säin eegene Socket a mellt e Wee deen d'weidergeleete Pak ni huelen wäert:

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

Wann déi Äntwert den Uplink nennt, ass den Tunnel net am Bild an eng Astellung op der Tunnel-Säit hëlleft net.

Brénge de Gaascht op dem Tunnel seng eege Adress

Déi klengst funktionéierend Ännerung ass eng explizit Quell-Ëmschreifung um Ausgang. Setzt se an, amplaz se unzehänken: Docker sëtzt schonn un der Spëtzt vun POSTROUTING, dofir gëtt eng Regel déi mat -A bäigefüügt gëtt hannert där vum Docker evaluéiert a laskelt ni aus.

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

Zwou Konditioune bestëmmen ob dat hält. D'Adress muss eng sinn déi de Client wierklech huet, also pinnt se mat engem Andrag pro Client dee ifconfig-push 10.8.0.10 255.255.255.0 enthält; eng Regel déi eng Adress nennt déi ni zougewisen gouf produzéiert stille Verlëschter, keen Feeler. An d'Géigesäit muss déi Quell akzeptéieren an Äntwerten zréck leeden, dofir nennt eng Erlaabneslëscht do d'Tunneladress an net de Gaascht-Subnetz. Wann d'Clientadress dynamesch ass, -j MASQUERADE mat -o tun0 follegt deem wat d'Interface huet, um Präis vun enger Géigepolitik géint déi Dir kee feste Wäert schreiwe kënnt.

D'Filteren ass déi aner Hallschent. Docker setzt d'Politik FORWARD op drop a leiert d'Ketten déi et besëtzt bei all Daemon-Neistart, also setzt lokal Politik an DOCKER-USER, déi iwwerlieft:

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

D'Zeréckregel ass wichteg: eng Äntwert déi op tun0 ukomm ass fir eng Verbindung déi d'Bréck opgemaach huet gëtt net just akzeptéiert well d'Richtung eraus et war.

Halt den Host direkt mat enger Quellregel

Wann déi ganz Bréck den Tunnel soll benotzen awer soss näischt um Host, spréngt NAT an gitt där Quell hir eege Tabell. Gaaschtadressen bleiwen dann vun engem Enn zum aneren ze gesinn.

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

Regele ginn virun der Haapttabell consultéiert, an from entsprécht der Quell. Dem Tunnel seng eege baussenzeg Paken droen dem Host seng physesch Quell, dofir entsprieche se ni from 172.18.0.0/16 an den Tunnel kann sech net selwer zréck an sech leeden. Genee déi Selbstausschléissung mécht d'Anlag stabil.

Den Zeréckwee brauch elo Hëllef. D'Géigesäit gesäit eng net iwwersat 172.18.0.x an huet kee Grond ze wëssen wou se wunnt. Um Server brauch eng Datei pro Client iroute 172.18.0.0 255.255.0.0, sou datt dem Server seng intern Tabell dee Prefix dësem Client gëtt, an eng gestouss route 172.18.0.0 255.255.0.0, sou datt aner Cliente wëssen datt et se gëtt.

Zwou Kontrollen ier Dir et vertraut. Féiert ip route show default aus: mat redirect-gateway def1 huet d'Tabell 0.0.0.0/1 an 128.0.0.0/1 iwwer tun0, an den Host ass ganz a guer net direkt, well déi Hallef-Defaulten gewannen ouni default z'ersetzen. Regele bäigefüügt mat ip rule add verschwannen och beim Neistart, dofir dro se an engem up-Skript.

D'Pakegréisst ass deen zweeten Ausfall deen Dir begéint

Eng Bréck-Interface op 1500 Byte gëtt dem Tunnel méi wéi en droe kann wann déi baussenzeg UDP- an IP-Käpp bäikommen. Kleng Auswiesslungen ginn duerch, also léist DNS sech op an den TLS-Handshake fäerdeg, duerno hänkt en gréisseren Eropluede senza Feeler iergendwou. Den Ofsender widderhëlt déi selwecht Segmentgréisst well d'ICMP-Message iwwer Fragmentatioun, déi him soe géif ze schrumpfen, ni ukommt.

Fleckt et op der Interface, un der MSS, oder béides. D'Klemmen brauch keng MATAarbecht vum Gaascht:

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

D'Klemmen schreift nëmmen TCP ëm. UDP, QUIC abegraff, brauch amplaz eng méi niddreg Gaascht-Interface, mat --opt com.docker.network.driver.mtu=1400 beim Netzwierk erstellen oder dem passenden compose-Schlëssel.

DNS an d'Kontrollen déi et wäert sinn ze widderhuelen

D'Nimm-Aufléisung follegt dem selwechte Wee. Dem Docker säin agebaute Resolver op 127.0.0.11 leet un déi konfiguréiert Server vum Host weider, also ierft en Container wat den Host benotzt. Wa privat Zone nëmmen vun engem Resolver beäntwert gëtt deen iwwer den Tunnel erreechbar ass, richt de Gaascht op déi Adress, a test mat getent hosts bannent dem Container an net um Host.

  • Féiert de faalege Request bannent dem Gaascht aus; en Test op der Host-Säit benotzt eng aner Quelladress a verstoppt de Problem.
  • Liest d'Zieler op den NAT- a Filterregelen déi Dir bäigefüügt hutt. Eng Regel ouni eenzeg Iwwereneestëmmung ass e Routingfeeler, kee Politikfeeler.
  • Bestätegt datt d'Tunneladress an Ärer SNAT-Regel eng ass déi de Client wierklech huet.
  • Setzt dem Gaascht seng MTU erof oder klemt d'MSS ier Dir de Server fir en Hänger beschëllegt.

Schafft déi Lëscht erof a stoppt beim éischten Ausfall. Dëse Layer ass deen ze flécken; alles wat méi wäit ënnen dobäi kënnt verstoppt just d'Grenz déi brécht.

Ähnlech Artikelen