هغه Docker او WSL ټرافیک سم کړئ چې د کوربه VPN له پامه غورځوي

دغه پسرلی مې د یوې سهار ډېره برخه د یو کانټینر په تعقیب کې تېره کړه چې یو هم داخلي نوم نه شو حل کولی، په داسې حال کې چې څنګ ته براوزر ویکی پرته له کوم شکایت خلاصوله. تونل پورته و، براوزر دا ثابته کوله، او کانټینر په بل شبکه یي نوم ځای کې و چې بېله لار-جدول او بېل حلونکی یې درلود. هغه څه چې راځي دا هغه ترتیب دی چې اوس یې ګورم: لومړی د لارو جدولونه، دوهم د نومونو حل، دریم لېږد او په پای کې د کوربه پلیټفارم. په لومړي ګام کې ودرېږئ چې لا له وړاندې ناکام دی، ځکه چې په سټیک کې لاندې قواعد زیاتول پوله پټوي نه دا چې ګرځوي یې.

له دې مخکې چې یو قانون بدل کړئ، درې لار-جدولونه پرتله کړئ

د Docker په اصلي پل کې کانټینر یو اصلي لار لري چې docker0 دروازې ته ځي او نه پوهېږي چې tun0 شته. کوربه tun0، هغه لارې چې VPN زور ورکړی، او شاید یو د تګلارې قانون ولري چې ازموینه ټرافیک له هغې بېلې برخې وباسي چې تاسو یې تمه لرئ. WSL خپل مجازي اډاپټر تر شا درېیم جدول زیاتوي. تر هغه مخکې چې یو یې سمول غواړئ، درې واړه چاپ کړئ.

که د کانټینر یوازینې لار پل وي او tun0 هیڅکله د هغه په نوم ځای کې نه ښکاري، نو لاندې هیڅ شی به مرسته ونه کړي: هیڅ د نوم سرور بدلون لار نه جوړوي، او هیڅ لار داسې تونل هویت نه جوړوي چې همکار به یې ومني. ترتیب مهم دی ځکه چې د DNS ناکامي او د لار ناکامي د شیل له داخله یو شان ښکاري.

حلونکی تونل ته وټاکئ نه یو عام ته

پر کوربه، resolvectl status د هرې اړیکې لپاره DNS سرورونه لیستوي، او readlink -f /etc/resolv.conf درته وایي چې فایل systemd سټب دی، NetworkManager فایل دی، که هغه څه چې د یو عرضه کوونکي کلاینټ بیا لیکلی. د کاروونکي ټاکل شوې شبکې په کانټینر کې دننه، /etc/resolv.conf نوم اخلي 127.0.0.11, د Docker داخلي حلونکی، چې هغه upstream ته لېږي چې ډیمون ورسره تنظیم شوی و. خو د اصلي پل کانټینر د جوړېدو پر مهال د کوربه فایل یوه کاپي واخیسته او هغه ساتي.

هماغه کاپي لامل دی چې د کانټینر له پیل وروسته پورته کېدونکی تونل کانټینر پر زوړ upstream پوښتنه کوي. یا د VPN حلونکی په ښکاره ډول د دې سره ولېږئ docker run --dns 10.8.0.53, یا "dns": ["10.8.0.53"] کې /etc/docker/daemon.json وټاکئ او ډیمون بیا پیل کړئ، یا کله چې تونل پورته شو کانټینر بیا جوړ کړئ. بیا جوړول معمولاً له یو ساعت مخکې سم حلونکي د ډیبګ کولو نه ارزانه دی.

عام حلونکی ایښودل هغه ترمیم دی چې نښه ساتي. دا انټرنیټ حل کوي خو په هر خصوصي زون کې ناکامیږي، او کولای شي هغه فلټرول په چوپه توګه پرېږدي چې تونل د هغه لپاره شته. که وغواړئ د یو روان کانټینر /etc/resolv.conf دننه ولیکئ، تمه وکړئ Device or resource busy: Docker هغه فایل bind-mount کوي، نو سمون لومړی انماؤنټ غواړي. --dns د جوړېدو پر مهال ټاکل هغه ترتیب دی چې بیا پیل ته دوام ورکوي.

کله چې کانټینرونه تونل پور واخلي، ولېږئ او وژباړئ

د اصلي پل سره، کوربه د docker0 او tun0 تر منځ راؤټر دی، او په اصلي ډول دواړه کارونه نه کوي. لېږد فعال کړئ او سرچینه پته وژباړئ ترڅو همکار د کوربه تونل پته وویني نه هغه پته چې بیرته لار نه لري (tun0 د هغه نوم سره بدل کړئ چې ستاسو کلاینټ برخې ته ورکوي):

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 قواعد پر هغو کوربه مهم دي چې د لېږد تګلاره یې DROP ده. Docker خپل ځنځیرونه ورننباسي، نو د لوستلو پر ځای د بنډل سره ازموینه وکړئ iptables -S: له کانټینر، ip route get 10.8.0.20 باید د پل دروازې نوم واخلي، او nc -vz 10.8.0.20 443 باید پر تونل ونه ښکېږي یا وخت یې پای ته ورسېږي، نه پر حلونکي.

پرته له MASQUERADE همکار 172.17.0.0/16 ته بیرته لار غواړي، چې ډېری لیرې لاسرسي VPN به یې نه زور ورکوي. دلته هم د تګلارې پر بنسټ کلاینټ پلان ماتوي: که یوازې د ځانګړو UID یا cgroups ټرافیک ونيسي، ستاسو لېږد قواعد به هیڅکله په تونل کې بنډل ونه ویني، او سمون iptables کې نه، بلکې د کلاینټ په راؤټینګ تګلاره کې دی. په لاس زیات شوي قواعد د بیا پیل پر مهال ورک شي، نو هغه په systemd واحد یا netfilter-persistent جدول کې کېږدئ او له بیا پیل وروسته بیا ازموینه وکړئ، ځکه چې ناوخته پورته کېدونکی تونل کولای شي هغه وشوی.

کله چې هدف جلاوالی وي، تونل د کانټینر دننه کېږدئ

که یو کانټینر باید د یو ځانګړي نوډ له لارې ووځي، کلاینټ په هماغه کانټینر کې وچلوئ. هغه ته --cap-add NET_ADMIN او --device /dev/net/tun ته اړتیا ده، او بیا خپل tun0، لارې او فایر وال لري. که نور کانټینرونه ورسره تېر شي، هغه ته د کانټینر دننه لېږد او MASQUERADE قاعده هم اړینه ده، او هغو همکارانو ته اړینه ده چې یوه ښکاره لار یا پروکسي ورته اشاره وکړي؛ د Docker اصلي پل هغه لار ستاسو لپاره نه زیاتوي.

د کوربه شبکه، docker run --network host, ارزانه بڼه ده: کانټینر د کوربه نوم ځای ته ورګډ شي او د تونل لارې مستقیم وویني. دا د شبکې جلاوالی هم غورځوي، د پورټ ټکر ته بلنه ورکوي، او په عمل کې د Linux انتخاب دی. خپرېدلې پورټ بدیل نه دی. -p 8080:80 خدمت له کوربه لاسرسي وړ کوي؛ داخلي 10.x پتې د کانټینر له داخله لاسرسي وړ نه کوي، او دواړه ګډول هماغه لار ده چې د راؤټینګ ستونزه په یو خلاص ډیټابیس پورټ بدلېږي.

د نوم ناکامي له یوې پوښل شوې فرعي شبکې څخه بېله کړئ

د Docker اصلي پل 172.17.0.0/16 دی، او ډېری کارپوریټ VPN حوضونه د 172.16.0.0/12 دننه دي. کله چې تونل هغه ساحه ولري، د کانټینر لپاره ټاکل شوی ټرافیک کولای شي پرځای یې تونل ته ولېږل شي. نومونه ناکامېږي، تېروتنه DNS ته ورته ښکاري، او ستونزه په پتو کې ده. د رسېدو ځای وګورئ، نه حلونکی: ip route get 172.17.0.5 پر کوربه، بیا د پل مخکښ د VPN حوض او docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}' سره پرتله کړئ.

ترمیم دا دی چې یوه ساحه وګرځوئ: یا د Docker لپاره بله اصلي پته حوض daemon.json کې، یا په مرکزونکي کې بل حوض. دلته بل د نوم سرور زیاتول هیڅ نه کوي، او ssh -b هم نه: کلاینټ برخې ته تړل سرچینه پته بدلوي، نه هغه رسېدونکې لار چې تونل ته ځي. چټکه کاري وېش: هغه نوم چې پر کوربه حل شي خو په کانټینر کې نه، د حلونکي ستونزه ده، پداسې حال کې چې یو مستقیم IP اړیکه چې په کانټینر کې ځنډېږي خو پر کوربه کار کوي، د لار یا لېږد ځنځیر ستونزه ده.

WSL او Docker Desktop د Linux قواعد نه تعقیبوي

په خپل اصلي NAT حالت کې، WSL خپل مجازي اډاپټر تر شا ناست دی او د Windows VPN داخلي لارې یا DNS پسوندونه نه اخلي، له همدې امله براوزر کار کوي او ping د وېش دننه نه. په وروستیو Windows 11 جوړښتونو کې شته آینې شبکه پرځای د کوربه برخې شریکوي، خو باید په .wslconfig کې فعاله شي او وېش د wsl --shutdown سره بیا پیل شي. فعال حالت د wslinfo --networking-mode سره تایید کړئ، مخکې له دې چې ترمیم پلي کړئ، ځکه چې د NAT ځواب د آینې حالت لپاره غلط دی او برعکس.

Docker Desktop بله پوړ زیاتوي. پر Windows Linux کانټینرونه د NAT هغې پلي کېدنې تر شا ناست دي چې تاریخي نوم یې vpnkit دی، او لار یې له اصلي Linux کوربه توپیر لري. Windows کانټینرونه د Hyper-V مجازي سویچ له لارې نښلېږي، او یو کارپوریټ کلاینټ کولای شي له هغه سویچ څخه ټرافیک بند کړي، نو په ورته ماشین کې Linux کانټینرونه کولای شي شبکې ته ورسیږي خو Windows کانټینرونه هیڅ نه لري. یو بهرنی سویچ چې فزیکي اډاپټر ته تړل شوی وي معمول حل دی، او د کانټینر شبکه یي هویت په داسې لارو بدلوي چې تګلاره یې اجازه نه ورکوي.

تر هغه مخکې چې بل قانون ولیکئ، څلور پوړونه په ترتیب وګرځئ او چېرته چې یو یې غلط وي ودرېږئ:

• د کانټینر دننه: آیا ip route خصوصي مخکښ ته رسیږي، او آیا /etc/resolv.conf هغه upstream نوم اخلي چې حل یې کوي؟
• پر کوربه: آیا لېږد فعال دی، آیا NAT د تونل برخې ته تړل شوی، او آیا د لېږد ځنځیر له پل څخه تونل ته اجازه ورکوي؟
• پر همکار: آیا د بیرته لار پوهېږي، یا پر NAT تکیه کوئ چې د کانټینر فرعي شبکه پټه کړي؟
• پر پلیټفارم: آیا WSL په NAT یا آینې حالت کې دی، او کانټینر Linux دی که Windows؟

هره ازموینه په نوي کانټینر یا شیل کې بیا وچلوئ. هغه اوږده پروسه چې کیش شوی ځواب یا جوړه شوې اړیکه لري، به له دې وروسته هم ناکامه وي چې تنظیم سم شي، او هغه ناکامي په سمه توګه هغه ترمیم ته ورته ده چې کار نه کوي.