Fixéiert den Docker- an WSL-Trafic, deen de Host-VPN ignoréiert

Ech hunn de gréissten Deel vun engem Moien dëst Fréijoer domat verbruecht, engem Container nozejagen, deen een eenzegen internen Numm net konnt opléisen, während de Browser dernieft d'Wiki ouni Klo opgemaach huet. Den Tunnel war uewen, de Browser huet et bewisen, an de Container souz an engem aneren Netz-Nummraum mat enger anerer Rutentabelle an engem aneren Resolver. Wat duerno kënnt, ass d'Uerdnung, déi ech elo kontrolléieren: fir d'éischt Rutentabellen, duerno Opléisung, drëttens Weiderleeung a schlussendlech d'Host-Plattform. Halt bei deem éischte Schrëtt un, deen schonn feelt, well Reegelen ënner am Stack derbäisetzen d'Grenz verstoppt, amplaz se ze verréckelen.

Vergläicht déi dräi Rutentabellen, ier Dir eng Reegel ännert

E Container um Standard-Bridge vun Docker huet eng Standard-Rut op de docker0-Gateway an huet keng Ahnung, datt tun0 existéiert. Den Host huet tun0, d'Ruten, déi de VPN gedroe huet, a vläicht eng Politikreegel, déi Prüftrafic iwwer eng aner Interface schéckt, wéi Dir erwaart. WSL setzt eng drëtt Tabell hannert säin eegenen virtuelle Adapter. Dréckt all dräi aus, ier Dir eng dovun ännert.

Wann dem Container seng eenzeg Rut de Bridge ass an tun0 ni a sengem Nummraum erschéngt, hëlleft näischt hei drënner: keng Numm-Server-Ännerung schaaft eng Rut, an keng Rut schaaft eng Tunnel-Identitéit, déi de Peer akzeptéiert. D'Uerdnung ass wichteg, well en DNS-Feeler an e Rutefehler vun bannen an enger Shell identesch ausgesinn.

Riicht de Resolver op den Tunnel amplaz op en ëffentlechen

Um Host, resolvectl status listet DNS-Server pro Verbindung op, an readlink -f /etc/resolv.conf seet Iech, ob d'Datei de systemd-Stub ass, eng NetworkManager-Datei oder eppes, wat e Client vun engem Fournisseur ëmgeschriwwen huet. Bannen an engem Container op engem benotzerdefinéierten Netz, /etc/resolv.conf nennt 127.0.0.11, den agebaute Resolver vum Docker, deen op deen Upstream weiderleet, mat deem den Daemon konfiguréiert war. En Container um Standard-Bridge krut awer bei senger Erstellung eng Kopie vun der Host-Datei a behält se.

Déi Kopie ass de Grond, firwat en Tunnel, deen nom Start vum Container eropkënnt, de Container dee alen Upstream froe léisst. Entweder gitt de VPN-Resolver explizit mat docker run --dns 10.8.0.53 weider, oder setzt "dns": ["10.8.0.53"] an /etc/docker/daemon.json a startet den Daemon nei, oder erstellt de Container nei, wann den Tunnel uewen ass. Nei erstellen ass meeschtens méi bëlleg wéi e Resolver ze debuggen, deen virun enger Stonn richteg war.

En ëffentleche Resolver anzebauen ass déi Reparatur, déi de Symptom behält. Hie léist d'Internet op a feelt an all privater Zon, an hie kann d'Filterung, fir déi den Tunnel existéiert, roueg ëmgoen. Wann Dir versicht, bannen an /etc/resolv.conf vun engem lafende Container ze schreiwen, erwaart Device or resource busy: Docker bind-mount dës Datei, dofir brauch d'Ännerung fir d'éischt en Unmount. --dns bei der Erstellung ze setzen ass déi Sequenz, déi en Neistart iwwersteet.

Leet weider a iwwersetzt, wann Container den Tunnel léinen

Mat dem Standard-Bridge ass den Host e Router tëscht docker0 an tun0, an e mécht standardméisseg keng vun deenen zwou Aufgaben. Aktivéiert d'Weiderleeung an iwwersetzt d'Quelladress, sou datt de Peer eng Tunneladress vum Host gesäit amplaz eng, op déi en keng Retourrut huet (ersetzt tun0 duerch den Numm, deen Äre Client der Interface gëtt):

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

D'FORWARD-Reegelen zielen op Hosts, deenen hir Weiderleeungspolitik DROP ass. Docker setzt seng eege Ketten an, dofir testt mat engem Pak amplaz ze liesen iptables -S: vum Container aus, ip route get 10.8.0.20 soll de Bridge-Gateway nennen, an nc -vz 10.8.0.20 443 soll um Tunnel verbannen oder oflafen, net um Resolver.

Ouni MASQUERADE brauch de Peer eng Retourrut op 172.17.0.0/16, déi déi meescht Fernzougriffs-VPNen net drécken. Hei geet och de Plang vun engem politikbaséierte Client futti: wann hien nëmmen den Trafic vun bestëmmten UIDen oder cgroups fänkt, gesinn Är Weiderleeungsregele de Pak ni bannen am Tunnel, an d'Korrektur gehéiert an d'Routingpolitik vum Client an net an iptables. Reegelen, déi vun Hand derbäigesat ginn, verschwannen beim Neistart, dofir setzt se an eng systemd-Eenheet oder eng netfilter-persistent-Tabell a testt no engem Neistart nach eng Kéier, well en Tunnel, deen ze spéit eropkënnt, se ewechkëschte kann.

Setzt den Tunnel an de Container, wann Isolatioun d'Zil ass

Wann ee Container muss duerch ee bestëmmten Node erausgoen, lued de Client an deem Container. En brauch --cap-add NET_ADMIN an --device /dev/net/tun, an dann huet en säin eegenen tun0, seng Ruten a seng Firewall. Wann aner Containere duerch hien duerchgoen, brauch en och Weiderleeung an eng MASQUERADE-Reegel bannen am Container, an déi Peeren brauchen eng explizit Rut oder e Proxy, deen op hien weist; dem Docker säi Standard-Bridge setzt déi Rut net fir Iech derbäi.

Host-Netzwierk, docker run --network host, ass déi bëlleg Versioun: de Container trëtt dem Host sengem Nummraum bäi a gesäit d'Tunnelruten direkt. Et verzicht awer op d'Netzisolatioun, luet Portkollisiounen an an der Praxis ass et eng Linux-Optioun. En publizéierte Port ass keng Ersatz. -p 8080:80 mécht en Déngscht vum Host aus erreechbar; et mécht intern 10.x-Adressen net vun bannen am Container erreechbar, an déi zwee ze verwiesselen ass de Wee, op deem aus engem Routingproblem en oppene Datebankport gëtt.

Ënnerscheet en Nummfeeler vun engem iwwerlappenden Subnet

Dem Docker säi Standard-Bridge ass 172.17.0.0/16, a vill Entreprise-VPN-Pools leien an 172.16.0.0/12. Soubal den Tunnel dee Beräich huet, kann Trafic, deen fir e Container geduecht ass, amplaz an den Tunnel gerout ginn. Nimm feele, de Feeler gesäit aus wéi DNS, an d'Adressen sinn de Problem. Kontrolléiert d'Destinatioun, net de Resolver: ip route get 172.17.0.5 um Host, vergläicht dann de Bridge-Präfix mam VPN-Pool a mat docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'.

D'Reparatur ass, ee vun de Beräicher ze verréckelen: entweder en aneren Standardadresspool fir Docker an daemon.json oder en aneren Pool um Konzentrator. En aneren Numm-Server derbäisetzen mécht hei näischt, an ssh -b och net: de Client un eng Interface bannen ännert d'Quelladress, net eng Destinatiounsrut, déi an den Tunnel weist. Schnell Aarbechtsdeelung: en Numm, deen um Host opgeléist gëtt, awer net am Container, ass e Resolverproblem, während eng direkt IP-Verbindung, déi am Container hänkt, awer um Host fonctionéiert, e Rut- oder Weiderleeungskettenproblem ass.

WSL an Docker Desktop follegen net de Linux-Reegelen

A sengem Standard-NAT-Modus sëtzt WSL hannert sengem eegenen virtuelle Adapter a kritt weder déi intern Ruten nach d'DNS-Suffixe vum Windows-VPN, dofir fonctionéiert de Browser an ping bannen an der Distributioun net. Gespigelt Netzwierk, verfügbar an neie Windows 11-Builden, deelt amplaz d'Interface vum Host, awer et muss an .wslconfig aktivéiert ginn an d'Distributioun mat wsl --shutdown nei gestart ginn. Bestätegt den aktive Modus mat wslinfo --networking-mode ier Dir eng Korrektur uwent, well d'NAT-Äntwert fir de gespigelte Modus falsch ass an ëmgedréit.

Docker Desktop setzt nach eng Schicht derbäi. Linux-Containeren op Windows sëtzen hannert enger NAT-Implementatioun, déi historesch vpnkit genannt gëtt, an hire Wee ënnerscheet sech vun engem native Linux-Host. Windows-Containeren verbannen sech iwwer en Hyper-V-virtuelle Switch, an e Client vun engem Entreprise kann den Trafic vun deem Switch blockéieren, dofir kënnen Linux-Containeren op der selwechter Maschinn d'Netz erreechen, während Windows-Containeren näischt hunn. En externen Switch, deen un den physikaleschen Adapter gebonnen ass, ass de gewéinleche Wee ronderëm, an e ännert d'Netzidentitéit vum Container op eng Manéier, déi d'Politik vläicht net erlaabt.

Ier Dir nach eng Reegel schreift, gitt déi véier Schichten an der Uerdnung duerch a stoppt do, wou eng dovun falsch ass:

• Bannen am Container: erreecht ip route de private Präfix, an nennt /etc/resolv.conf en Upstream, deen en opléist?
• Um Host: ass d'Weiderleeung un, ass NAT un d'Tunnelinterface gebonnen, an akzeptéiert d'Weiderleeungskette Bridge zu Tunnel?
• Um Peer: kennt hien eng Retourrut, oder verloosst Dir Iech op NAT, fir de Container-Subnet ze verstoppen?
• Op der Plattform: ass WSL am NAT- oder am gespigelte Modus, an ass de Container Linux oder Windows?

Fëllt all Test an engem frëschen Container oder enger Shell nach eng Kéier aus. En laang lafende Prozess mat enger gecachter Äntwert oder enger etabléierter Verbindung wäert weider feelen, nodeems d'Konfiguratioun richteg ass, an dee Feeler gesäit genau aus wéi eng Reparatur, déi net fonctionéiert huet.