Konpondu hostaren VPN-a baztertzen duen Docker eta WSL trafikoa

Udaberri honetan goiz baten zatirik handiena eman nuen barneko izen bakar bat ere ebatzi ezin zuen kontenedore baten atzetik, ondoan zegoen nabigatzaileak wikian kexarik gabe irekitzen zuen bitartean. Tunela igota zegoen, nabigatzaileak frogatzen zuen, eta kontenedorea beste sare-izen-espazio batean zegoen, beste ibilbide-taularekin eta beste ebazlearekin. Hona hemen orain egiaztatzen dudan hurrenkera: lehenik ibilbide-taulak, bigarrenik ebazpena, hirugarrenik birbidaltzea eta azkenik hostaren plataforma. Gelditu jada huts egiten duen lehen urratsean, pilaren behealdean arauak gehitzeak muga ezkutatzen duelako, mugitu beharrean.

Konparatu hiru ibilbide-taulak arau bat aldatu aurretik

Dockerren zubi lehenetsian dagoen kontenedoreak docker0 atebidera doan ibilbide lehenetsi bakarra du, eta ez daki tun0 existitzen denik. Hostak tun0 du, VPNak bultzatutako ibilbideak eta agian zundaketa-trafikoa espero duzunaz bestelako interfaze batetik bidaltzen duen politika-araua. WSLk hirugarren taula gehitzen du bere adaptagailu birtualaren atzean. Inprimatu hirurak horietako edozein editatu aurretik.

Kontenedorearen ibilbide bakarra zubia bada eta tun0 ez bada inoiz agertzen bere izen-espazioan, beheko ezerk ez du lagunduko: nire zerbitzari-aldaketak ez du ibilbiderik sortzen, eta ibilbide batek ere ez du peer-ak onartuko duen tunel-identitaterik sortzen. Hurrenkerak garrantzia du, DNS hutsak eta ibilbide hutsak berdinak diruditelako shell baten barrutik.

Zuzendu ebazlea tunelera, publiko batera beharrean

Hostean, resolvectl status DNS zerbitzariak zerrendatzen ditu esteka bakoitzeko, eta readlink -f /etc/resolv.conf esaten dizu fitxategia systemd stub, NetworkManager fitxategi edo hornitzaile baten bezeroak berridatzitako zerbait den. Erabiltzaileak definitutako sare batean dagoen kontenedore baten barruan, /etc/resolv.conf izena ematen dio 127.0.0.11, Dockerren ebazle integratuak, daemona konfiguratu zen upstream-era birbidaltzen duena. Zubi lehenetsiko kontenedoreak, aldiz, hostaren fitxategiaren kopia bat jaso zuen sortu zenean, eta mantendu egiten du.

Kopia hori da kontenedorea abiatu ondoren igotzen den tunelak kontenedorea upstream zaharrari galdetzen uztearen arrazoia. Edo pasa VPNaren ebazlea modu esplizituan honekin docker run --dns 10.8.0.53, edo ezarri "dns": ["10.8.0.53"] hemen /etc/docker/daemon.json eta berrabiarazi daemona, edo birsortu kontenedorea tunela igota dagoenean. Birsortzea normalean ordu bat lehenago zuzena zen ebazle bat araztea baino merkeagoa da.

Ebazle publiko bat jartzea sintoma mantentzen duen konponketa da. Interneta ebazten du eta zona pribatu guztietan huts egiten du, eta isil-isilik saihestu dezake tunelak betearazteko duen iragazketa. Lanean ari den kontenedore baten /etc/resolv.conf barruan idazten saiatzen bazara, espero Device or resource busy: Dockerek fitxategi hori bind-mount egiten du, beraz edizioak desmuntatzea behar du lehenengo. --dns sortzean ezartzea berrabiarazteari eusten dion sekuentzia da.

Birbidali eta itzuli kontenedoreek tunela maileguan hartzen dutenean

Zubi lehenetsiarekin, hosta docker0 eta tun0 arteko bideratzailea da, eta lehenespenez ez du bi lanetako bat ere egiten. Aktibatu birbidaltzea eta itzuli iturburu-helbidea, peer-ak hostaren tunel-helbidea ikus dezan, atzera-ibilbiderik ez duen helbide baten ordez (ordezkatu tun0 zure bezeroak interfazeari ematen dion izenarekin):

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

FORWARD arauak garrantzitsuak dira birbidaltze-politika DROP duten hostetan. Dockerek bere kateak txertatzen ditu, beraz probatu pakete batekin iptables -S: kontenedoretik, ip route get 10.8.0.20 zubiaren atebidea izendatu behar du, eta nc -vz 10.8.0.20 443 tunelean konektatu edo denbora agortu behar du, ebazlean ez.

MASQUERADE gabe peer-ak 172.17.0.0/16ra itzultzeko ibilbidea behar du, urruneko sarbideko VPN gehienek ez dutena bultzatuko. Hemen ere politikan oinarritutako bezero batek plana hausten du: UID edo cgroups zehatzen trafikoa soilik harrapatzen badu, zure birbidaltze-arauak ez du inoiz paketea tunelaren barruan ikusten, eta konponketa bezeroaren bideratze-politikari dagokio, ez iptables-i. Eskuz gehitutako arauak berrabiaraztean desagertzen dira, beraz jarri itzazu systemd unitate batean edo netfilter-persistent taula batean eta probatu berriro berrabiarazi ondoren, berandu igotzen den tunel batek arrastatu ditzakeelako.

Jarri tunela kontenedorearen barruan isolamendua helburua denean

Kontenedore batek nodo zehatz batetik atera behar badu, exekutatu bezeroa kontenedore horretan. Honek behar du --cap-add NET_ADMIN eta --device /dev/net/tun, eta orduan bere tun0, ibilbide eta suebaki propioak ditu. Beste kontenedore batzuk bertatik igarotzen badira, birbidaltzea eta MASQUERADE araua ere behar ditu kontenedorearen barruan, eta peer horiek berarengana doan ibilbide edo proxy esplizitua behar dute; Dockerren zubi lehenetsiak ez du ibilbide hori zuretzat gehitzen.

Hostaren sarea, docker run --network host, bertsio merkea da: kontenedorea hostaren izen-espaziora batu eta tunelaren ibilbideak zuzenean ikusten ditu. Sare-isolamendua ere uzten du, portu-gatazkak erakartzen ditu eta praktikan Linux aukera bat da. Argitaratutako portua ez da ordezko bat. -p 8080:80 zerbitzu bat hostetik irisgarri egiten du; ez du 10.x helbide internoak kontenedorearen barrutik irisgarri egiten, eta biak nahastea da bideratze-arazo bat datu-baseko portu esposatu bihurtzeko modua.

Bereizi izen-hutsa gainjarritako azpisare batetik

Dockerren zubi lehenetsia 172.17.0.0/16 da, eta VPN igerileku korporatibo asko 172.16.0.0/12 barruan daude. Tunelak barruti horren jabe egiten denean, kontenedore baterako trafikoa tunelean bidera daiteke horren ordez. Izenek huts egiten dute, erroreak DNS itxura du, eta helbideak dira arazoa. Egiaztatu helburua, ez ebazlea: ip route get 172.17.0.5 hostean, gero konparatu zubiaren aurrizkia VPN igerilekuarekin eta docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'-rekin.

Konponketa barruti bat mugitzea da: edo Dockerrentzako helbide-igerileku lehenetsi desberdin bat daemon.json fitxategian, edo igerileku desberdin bat kontzentratzailean. Beste izen-zerbitzari bat gehitzeak ez du ezer egiten hemen, eta ez du ssh -b ere: bezeroa interfaze batera lotzeak iturburu-helbidea aldatzen du, ez tunelean sartzen den helburu-ibilbidea. Lan-banaketa azkarra: hostean ebazten den baina kontenedorean ez den izena ebazle-arazoa da, eta kontenedorean zintzilik dagoen baina hostean funtzionatzen duen IP konexio zuzena ibilbide edo birbidaltze-kate arazoa da.

WSL eta Docker Desktop ez dira Linuxen arauetara makurtzen

Bere NAT modu lehenetsian, WSL bere adaptagailu birtualaren atzean dago eta ez ditu Windows VPNaren barne-ibilbideak edo DNS atzizkiak jasotzen, horregatik nabigatzaileak funtzionatzen du eta ping distribuzioaren barruan ez. Windows 11 build berrietan erabilgarri dagoen sare ispilatuak hostaren interfazeak partekatzen ditu horren ordez, baina .wslconfig fitxategian gaitu behar da eta distribuzioa wsl --shutdown erabiliz berrabiarazi. Egiaztatu modu aktiboa wslinfo --networking-mode erabiliz konponketa aplikatu aurretik, NAT erantzuna okerra delako ispilu modurako eta alderantziz.

Docker Desktopek beste geruza bat gehitzen du. Windowsen Linux kontenedoreak historikoki vpnkit deitzen zen NAT inplementazio baten atzean daude, eta haien bidea Linux host natiboarena ez bezalakoa da. Windows kontenedoreak Hyper-V etengailu birtual baten bidez konektatzen dira, eta bezero korporatibo batek etengailu horretako trafikoa blokea dezake, beraz makin bereko Linux kontenedoreek sarea irits dezakete Windows kontenedoreek ezer ez duten bitartean. Adaptagailu fisikora lotutako kanpoko etengailu bat da ohiko konponbidea, eta kontenedorearen sare-identitatea aldatzen du politikak onartzen ez duen moduetan.

Beste arau bat idatzi aurretik, ibili lau geruzak hurrenez hurren eta gelditu horietako bat oker dagoen tokian:

• Kontenedorearen barruan: iristen al da ip route aurrizki pribatura, eta /etc/resolv.conf izena ematen al dio hura ebazten duen upstream bati?
• Hostean: birbidaltzea aktibatuta dago, NAT tunelaren interfazera lotuta dago, eta birbidaltze-kateak onartzen du zubitik tunelera?
• Peer-ean: atzera-bidea ezagutzen du, edo NAT-en konfiantza duzu kontenedorearen azpisarea ezkutatzeko?
• Plataforman: WSL NAT edo ispilu moduan dago, eta kontenedorea Linux edo Windows da?

Exekutatu proba bakoitza berriro kontenedore edo shell berri batean. Erantzun katxeatua edo ezarritako konexioa dituen prozesu luze batek huts egiten jarraituko du konfigurazioa zuzena izan ondoren, eta huts horrek funtzionatu ez zuen konponketa baten itxura zehatza du.