WSL2 د شرکت VPN نه ترلاسه کوي، او همدا ستونزه ده
WSL2 په خپل مجازي شبکه کې ځي او د کوربه VPN سټک هېڅکله نه ترلاسه کوي. د resolv.conf له تعدیل مخکې د نومونو ناکامي له لارې ناکامۍ څخه جلا کړئ.
داخلي ویکي په Edge کې پرانیستل کیږي، خو د ویش داخل کې git clone وخت تېریږي. دا یوازینی مشاهده معمولاً د «VPN WSL2 بندوي» په توګه لوستل کیږي، او راتلونکی ساعت د /etc/resolv.conf په تعدیل تېریږي. لا ګټور لوستل دا دي چې WSL2 هېڅکله د کوربه شبکه لاره نه درلوده: دا په خپل اډاپټر، خپلو لارو او د Windows لخوا د هغې لپاره جوړ شوي resolver فایل سره په یوه مرستندویه VM کې ځي. هر څه چې وروسته راځي په دې پورې تړلي دي چې له هغو درېیو څخه کوم یو واقعاً تاسو ته نشته.
VM خپل سټک، متریک او resolver لري
په اصلي NAT حالت کې، ویش د یو مجازي سویچ شاته ناست دی او د کوربه له لارې انټرنیټ ته رسیږي، خو د کوربه اډاپټرونه نه ویني. ip addr یو انٹرفیس د خصوصي پتې سره ښیي، ip route د هغه سویچ له لارې اصلي لاره ښیي، او /etc/resolv.conf د Windows لخوا ټاکل شوي stub resolver ته اشاره کوونکی جوړ شوی فایل دی. له دې څخه هېڅ هم نه بدلیږي ځکه چې د Windows په اړخ کې VPN کلاینټ پیل شو.
نو ځکه «براوزر کار کوي» دومره لږ ثابتوي. براوزر د کوربه سټک، ټنل او د کوربه resolver پالیسي کاروي. ستاسو شیل بل سټک کاروي چې په تصادفي ډول یو فزیکي شبکه کارت شریکوي. دوی په ښه حالت کې سره سمون لري او په سمه توګه هغه وخت جلا کیږي چې VPN فلټر نصبوي، د DNS لیست بیا لیکي یا د مجازي سویچ سبنیټ لپاره لاره زیاتوي.
تاسو په کومه نړۍ کې یاست دا دوه ازموینې فیصله کوي، او دوی باید د ویش داخل کې وچلېږي:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confد نومونو ناکامي پداسې حال کې چې لفظي پته ځواب وایي د resolver ستونزه ده. د نومونو او پتو یوځای ناکامي د لارې ستونزه ده، او د resolver هېڅ تعدیل به ورته ونه رسیږي. بیا د Windows اړخ شواهد راځي: Get-NetAdapter | Get-DnsClientServerAddress او route print -4 ښیي چې ایا ټنل هغه سبنیټ نیولی چې ستاسو VM پکې اوسیږي.
لومړی خرافه: شرکت DNS سرورونه یې سمول کوي
د resolver فایل تعدیلول کلاسیک مشوره ده او نږدې نیمایي وخت سمه ده. کله چې سمه وي، په ځانګړي دلیل سمه ده: جوړ شوی فایل هغه resolver ته اشاره کوي چې یوازې عام نومونه پیژني، نو د intranet.example.internal لپاره پوښتنه د لارې سمېدو سره سره د نه شتون په توګه بیرته راځي.
د VPN سرورونه پن کول یعنې Windows له فایل بیا جوړولو منع کول، ځکه چې په لاس لیکل شوی هر فایل په راتلونکي پیل کې بدلیږي:
[network]
generateResolvConf = falseهغه د /etc/wsl.conf په توګه وساتئ، له Windows څخه wsl --shutdown وچلوئ، بیا ویش پیل کړئ او /etc/resolv.conf ولیکئ چې لومړی د ټنل سرورونه او یو عام resolver یوازې د بیک اپ په توګه وي. دا د ساتنې لګښت سره دوامداره بدلون دی: فایل نور کوربه نه تعقیبوي، نو کله چې د شرکت DNS پتې بدلې شي ویش بیا هم زاړه پوښتنه کوي. یو څوک باید د هغه فایل مالک وي.
کله چې ناکامي پراخه وي هم هېڅ نه کوي. که curl تر 1.1.1.1 وخت تېر شي، ټنل کلاینټ مجازي سویچ فلټر کوي یا د VM سبنیټ ټنل ته ځای پرځای کوي، او سم resolver تاسو ته یوازې هغه نومونه درکوي چې لا هم نشي رسېدلی.
دوهمه خرافه: د متریک بدلون پاتې کیږي
کله چې نومونه حل شي خو ټرافیک د فزیکي اډاپټر له لارې ووځي، د انٹرفیس متریکونه هغه اهر دي. VPN اډاپټر ته لوړ لګښت او WSL سویچ ته ټیټ ورکړئ:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1بیا په یاد ولرئ چې په ډیرو کلاینټ جوړښتونو کې ټنل اډاپټر په هر نښلون کې بیا جوړیږي او متریک خپل اصلي ارزښت ته راستنیږي. یوځله امر هغه سمون دی چې په چوپتیا پای ته رسیږي، معمولاً د اونۍ په پای کې، او ټکټ د «تېره اونۍ کار کاوه» سره بیرته راځي. د VPN پیښې لخوا پیل شوې مهالویش شوې دنده، یا هغه سکریپټ چې کاروونکی له نښلون وروسته چلوي، د دې سمون رښتینی نسخه ده.
هماغه موده د یوې سرسخته مخکښې لپاره زیات شوو کوربه لارو ته هم تطبیقیږي. د تشخیص په توګه دوی ارزښت لري، ځکه وایي چې ستونزه یو هدف دی که ټوله لاره، خو دوی معماري نه ده.
درېیمه خرافه: یو سمون هر Windows جوړښت پوښي
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit د sidecar نمونه ده: یو کوچنی ویش د کوربه اړخ لاره لري او د نورو ویشونو لپاره د مجازي ساکټ له لارې فوروارد کوي، نو د اپلیکیشن ټرافیک له فلټر شوي سویچ پورې تړلی پاتې کېدو څخه منځه ځي. د سټاک لاره باید کار وکړي، یعنې networkingMode او dnsTunneling اووررایډونه له %UserProfile%\.wslconfig څخه لرې کول، په هر فعال ویش کې generateResolvConf = true بیا رغول او په ننوتلو کې خدمت پیل کول.
د آینې حالت په Windows 11 22H2 او وروستیو کې جوړ شوی بدیل دی، او دا یوه تنظیم او یو بندول دي:
[wsl2]
networkingMode=mirroredد ویش داخل کې ip addr بیا د کوربه اډاپټرونه لیست کوي، ټنل ممکن د دوی په منځ کې ښکاره شي، او DNS ټنلینګ د Windows resolver له لارې پوښتنې فوروارد کوي حتی کله چې کلاینټ د DNS لیست بیا ولیکي. دا نړیوال نه دی: ځینې فلټر ډرایورونه لا هم آینې لاره غورځوي، او د Hyper-V وال فایر وړ قواعد ممکن څرګنده اجازه وغواړي. د Microsoft WSL شبکې لارښود هغه پاڼه ده چې باید د نوي لپاره لیکل شوي ترکیب له پلي کولو مخکې ستاسو له جوړښت سره پرتله شي.
له هر بدلون وروسته درې شیان وازموئ
د هر ماشین لپاره یو میکانیزم وټاکئ او ولیکئ، ځکه دواړه بد سره یوځای کیږي. په آینې حالت باندې sidecar فورواردینګ دوه چنده کوي، او .wslconfig کې زوړ sidecar داخلونه لرونکی آینې کوربه د لوړولو وروسته ناکام کیږي، نه مخکې.
هر څه چې مو ټاکلي، د منلو ازموینه په ویش کې هماغه درې غوښتنې دي: داخلي نوم، عام نوم او خام پته. بیا یې د ټنل د جلا کولو او بیا نښلولو وروسته، او د wsl --shutdown وروسته تکرار کړئ. یوازې داخلي نوم ناکامیدل resolver پالیسي ده؛ داخلي او عام نومونه یوځای ناکامیدل پداسې حال کې چې پته کار کوي بیا هم resolver پالیسي ده؛ هر څه ناکامیدل لاره ده.
که یو داخلي کوربه ناکام شي او نور کار وکړي، resolver ته کتل بند کړئ او د هغې مخکښې لپاره ورکه لاره ولټوئ. که هر څه تر راتلونکي بیا نښلون پورې کار وکړي، تاسو د اجرا وخت حالت پورې تړلی سمون موندلی، او باید په اتوماتیک ډول بیا پلي شي یا د پورتنو دوو میکانیزمونو په یو بدل شي.