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 ٹنلنگ کلائنٹ کے DNS فہرست دوبارہ لکھنے پر بھی Windows resolver کے ذریعے تلاشیں آگے بھیجتی ہے۔ یہ عالمگیر نہیں: بعض فلٹر ڈرائیورز اب بھی آئینہ راستہ چھوڑ دیتے ہیں، اور Hyper-V فائر وال قواعد کو واضح اجازت درکار ہو سکتی ہے۔ Microsoft کی WSL نیٹ ورکنگ گائیڈ وہ صفحہ ہے جسے نئے کے لیے لکھی گئی ترکیب لاگو کرنے سے پہلے اپنی بلڈ سے ملانا چاہیے۔
ہر تبدیلی کے بعد تین چیزیں جانچیں
ہر مشین کے لیے ایک میکانزم چنیں اور لکھ لیں، کیونکہ دونوں بری طرح ملتے ہیں۔ آئینہ موڈ کے اوپر sidecar آگے بھیجنا دوگنا کر دیتا ہے، اور .wslconfig میں پرانی sidecar اندراج والا آئینہ میزبان اپ گریڈ کے بعد ناکام ہوتا ہے، پہلے نہیں۔
آپ نے جو بھی چنا ہو، قبولیت کا ٹیسٹ ڈسٹری بیوشن کے اندر وہی تین درخواستیں ہیں: اندرونی نام، عوامی نام اور خام پتہ۔ پھر ٹنل منقطع اور دوبارہ منسلک کرنے کے بعد، اور wsl --shutdown کے بعد انہیں دہرائیں۔ صرف اندرونی نام کا ناکام ہونا resolver پالیسی ہے; اندرونی اور عوامی نام کا ساتھ ناکام ہونا جب پتہ کام کر رہا ہو تب بھی resolver پالیسی ہے; سب کچھ ناکام ہونا راستہ ہے۔
اگر ایک اندرونی میزبان ناکام ہو جائے جبکہ باقی کام کریں، تو resolver دیکھنا بند کریں اور اس سابقے کے لیے گمشدہ راستہ تلاش کریں۔ اگر اگلے دوبارہ کنیکشن تک سب کچھ کام کرے، تو آپ نے رن ٹائم حالت پر منحصر مرمت پائی ہے، اور اسے خودکار طور پر دوبارہ لاگو کرنا ہوگا یا اوپر کے دو میکانزم میں سے ایک سے بدلنا ہوگا۔