VPN جڑنے پر WSL کام کا ہوسٹ نام کیوں کھو دیتا ہے؟
وہی نام Windows میں کام کرتا ہے اور سرنگ بلند ہوتے ہی WSL کے اندر ناکام ہو جاتا ہے۔ ریزولور شامل کرنے سے پہلے پلیٹ فارم کا DNS موڈ اور پرانے اوور رائیڈز جانچیں۔
Windows اندرونی ہوسٹ کو کسی شکایت کے بغیر حل کرتا ہے، اور وہی نام سرنگ بلند ہونے کے لمحے WSL کے اندر ناکام ہو جاتا ہے۔ عام حل یہ ہے کہ تقسیم میں کوئی عوامی ریزولور لکھ دیا جائے، جو معمول کی براؤزنگ واپس لاتا ہے اور کام کے ہوسٹ نام کو ناقابل حل بنا دیتا ہے۔ یہ ایک ناکامی کو دوسری سے بدل دیتا ہے اور اصل میں ٹوٹی ہوئی پرت کو چھپا دیتا ہے۔ ریزولور کی کوئی بھی سطر شامل یا حذف کرنے سے پہلے طے کریں کہ تین پرتوں میں سے کون سی ناکام ہو رہی ہے۔
پہلے روٹنگ کی ناکامی کو خارج کریں
دونوں طرف وہی مکمل طور پر اہل نام پوچھیں، ایک جیسے دکھنے والے دو نام نہیں۔ ایک ہی سٹرنگ کے لیے Windows میں کامیابی اور WSL میں ناکامی دو حل راستوں کا دستخط ہے، اور یہ نمونہ اتنے صاف طور پر اور بہت کم چیزیں بناتی ہیں۔ اگر WSL اپنے معلوم عددی پتے پر بھی سروس تک نہ پہنچ سکے تو روٹنگ یا فلٹرنگ کا مسئلہ بھی موجود ہے۔ اس صورت میں DNS کا کام اسے ظاہر نہیں کرے گا، اور دوپہر غلط پرت پر چلی جائے گی۔
تین علامات ان میں سے بیشتر صورتوں کا احاطہ کرتی ہیں، اور ہر ایک الگ جگہ اشارہ کرتی ہے۔ کنفیگریشن فائل کھولنے سے پہلے موزوں سطر پڑھیں:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
درمیانی سطر وہ ہے جسے لوگ غلط پڑھتے ہیں، کیونکہ اسے توڑنے والی تبدیلی ہفتے پہلے کی گئی تھی اور اس وقت کامیاب دکھائی دیتی تھی۔ تیسری سطر وہ ہے جس کی لوگ غلط تشخیص کرتے ہیں، کیونکہ حل ہوتا نام نیٹ ورک کے صحت مند ہونے کا ثبوت لگتا ہے۔ دونوں سطریں آپ کو نیچے الگ حصے میں بھیجتی ہیں۔
DNS سرنگ کی ایک کم از کم ورژن حد ہے
Microsoft WSL کا ایک نیٹ ورکنگ موڈ دستاویز کرتا ہے جو ورچوئلائزیشن چینل کے ذریعے DNS درخواستیں Windows ریزولور تک سرنگ کرتا ہے۔ معاون Windows 11 بلڈز پر یہ بطور طے شدہ فعال ہوتا ہے، اسی لیے ایک ہی کارپوریٹ نیٹ ورک پر دو مشینیں مختلف برتاؤ کرتی ہیں۔ متغیر بلڈ نمبر ہے، کارپوریٹ پالیسی نہیں۔
WSL نیٹ ورکنگ گائیڈ اس موڈ اور اسے معاونت دینے والے ورژنوں کی وضاحت کرتی ہے۔ یہ خصوصیت اہم ہے کیونکہ کارپوریٹ DNS پالیسی عام طور پر Windows ریزولور میں رہتی ہے، اور Windows کا راستہ ورثے میں پانے والی تقسیم پالیسی بھی ساتھ لیتی ہے۔ عوامی ریزولور سے پوچھنے والی تقسیم کے پاس نجی نام تک کوئی راستہ نہیں ہوتا، اس کی اپنی کنفیگریشن کتنی ہی صاف دکھے۔ یہی طریقہ کار پوری علامت کی وضاحت کرتا ہے، اور یہ بھی بتاتا ہے کہ عوامی ریزولور والا حل کیوں ناکام ہوتا ہے۔
کچھ بھی ترمیم کرنے سے پہلے بلڈ پڑھیں۔ نئی انسٹالیشن سے کاپی کی گئی سیٹنگ اس بات کا ثبوت نہیں کہ پرانی اسے نافذ کرتی ہے۔ تبدیلی کے ساتھ بلڈ نمبر لکھیں، کیونکہ دو مشینوں کا فرق تقریباً ہمیشہ ورژن ہوتا ہے، پالیسی نہیں۔
پرانے اوور رائیڈز اپنی حل کردہ مسئلے سے زیادہ عرصہ زندہ رہتے ہیں
پرانے طریقے بنائی گئی ریزولور فائلیں غیر فعال کرتے تھے، نیم سرور کو ہارڈ کوڈ کرتے تھے، یا فائل کو ناقابل تبدیل خصوصیت سے لاک کرتے تھے۔ وہ تبدیلیاں ان کی پیدا کردہ کنیکٹیویٹی مسئلے کے ختم ہونے کے بہت بعد تک اپنی جگہ رہتی ہیں، اور عام طور پر یہی وجہ ہوتی ہے کہ نئی سیٹنگ کچھ نہ کرتی دکھتی ہے۔ وہ تقسیم کی دوبارہ تنصیب کے بعد بھی shell پروفائل کی شکل میں قائم رہتی ہیں، جو ہر لاگ ان پر فائل دوبارہ لکھتی ہے۔ آخری والی تلاش کرنا سب سے مشکل ہے، کیونکہ جس فائل کو سب جانچتے ہیں اس سے یہ نظر نہیں آتی۔
ہاتھ سے لکھی ریزولور فائل، اس پر ناقابل تبدیل خصوصیت، اور اسے دوبارہ لکھنے والی اسٹارٹ اپ اسکرپٹ تلاش کریں۔ ترمیم سے پہلے ناقابل تبدیل جھنڈا جانچیں، کیونکہ لاک شدہ فائل میں لکھنا اجازت کے مسئلے کی طرح پڑھے جانے والے انداز میں ناکام ہوتا ہے۔ پھر shell پروفائل جانچیں، کیونکہ وہاں کی اسکرپٹ آپ کی اصلاح کے چند سیکنڈ میں پرانا مواد واپس لاتی ہے۔
اوور رائیڈ ہٹانے کے نتائج ہوتے ہیں، اس لیے لکھیں کہ کیا ہٹایا اور کیوں۔ جس تقسیم کو واقعی کسی اور مقصد کے لیے جامد ریزولور درکار ہو وہ بنائی گئی فائل واپس آنے پر ٹوٹ جائے گی۔
دو فائلیں، دو مختلف کردار
دونوں کنفیگریشن فائلیں الگ جگہوں پر رہتی ہیں اور الگ چیزیں کنٹرول کرتی ہیں، اور انہیں ملانا غلط پرت پر لاگو ہونے والی ترامیم پیدا کرتا ہے۔ Windows کی طرف کی فائل ورچوئل مشین کی خصوصیات طے کرتی ہے، جبکہ تقسیم کی طرف کی فائل طے کرتی ہے کہ وہ تقسیم اپنی ریزولور کنفیگریشن کیسے بناتی ہے۔ کوئی بھی دوسری کو اوور رائیڈ نہیں کرتی، اسی لیے دونوں کو متفق ہونا پڑتا ہے۔
اس خصوصیت کی معاونت کرنے والی انسٹالیشن کے لیے Windows کی طرف کا ٹکڑا مختصر ہے۔ اس طرف کی پوری تبدیلی یہی ہے:
[wsl2]
dnsTunneling=trueوہ ٹکڑا Windows صارف پروفائل میں جاتا ہے اور ایک تقسیم کے بجائے ورچوئل مشین پر لاگو ہوتا ہے۔ سرنگ کے لیے یہ بھی ضروری ہے کہ تقسیم نے ریزولور کی پیداوار غیر فعال نہ کی ہو، اس لیے تقسیم کی طرف کی فائل کو یہ رویہ اپنی جگہ رہنے دینا چاہیے۔ ایک کو دوسرے کے بغیر بدلیں اور موڈ خاموشی سے کچھ نہیں کرتا، اور یہ اس اصلاح کے ٹوٹا ہوا بتائے جانے کا سب سے عام طریقہ ہے۔ دونوں فائلیں ایک ہی سیشن میں جانچیں، کیونکہ ہفتوں کے وقفے سے کی گئی دو ترامیم ایسی دو ترامیم ہیں جنہیں کوئی منسوب نہیں کر سکتا۔
دوبارہ شروع کریں، پھر دونوں طرف سے پوچھیں
یہ سیٹنگز ماحول شروع ہونے پر پڑھی جاتی ہیں، اس لیے چلتی تقسیم کے اندر نیا shell انہیں دوبارہ لوڈ نہیں کرے گا۔ shell دوبارہ شروع کرنے کے بجائے ماحول بند کریں، اور پہلے چل رہا کوئی بھی کام محفوظ کریں کیونکہ ہر تقسیم اس کے ساتھ رک جاتی ہے۔ صرف یہی کوتاہی تبدیلی کے بے اثر ہونے کی بیشتر رپورٹوں کی وضاحت کرتی ہے۔
پھر دونوں طرف وہی سوال پوچھیں۔ آؤٹ پٹ یہ بھی دکھاتا ہے کہ تقسیم آخر کار کس ریزولور کے ساتھ رہی:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'پہلا حکم ماحول ختم کرتا ہے، دوسرا دکھاتا ہے کہ تقسیم اب کون سا ریزولور استعمال کرتی ہے، اور آخری دو ہر طرف کو وہی سوال پوچھتے ہیں۔ سیٹنگ کی حالت نہیں، جوابات کا موازنہ کریں۔ دونوں فائلیں درست ہونے پر بھی صاف دوبارہ آغاز کے بعد ناکام ہونے والی استفسار کارپوریٹ ریزولور پالیسی کی طرف اشارہ کرتی ہے، اور اس گفتگو کا مالک کوئی اور ہے۔