VPN منسلک ہونے کے بعد WSL2 نے DNS کھو دیا؟ دو وجوہات
ایک پرانی resolver فائل اور مسابقتی روٹ میٹرک WSL2 کے اندر وہی علامت پیدا کرتے ہیں۔ دونوں طرف ریکارڈ کریں، پھر جو واقعی خراب ہے اسی کو ٹھیک کریں۔
پتے کے ذریعے ping تقسیم کے اندر کام کرتا ہے، پیکیج کی تنصیب اور git کھینچنا کام نہیں کرتے، اور خرابی ٹنل کے اوپر آنے کے فوراً بعد ظاہر ہوئی۔ صرف نام حل ہونا بند ہوا، جو DNS کی طرف اشارہ کرتا ہے، رابطے کی طرف نہیں۔ پیکیج دوبارہ انسٹال کرنا یہاں سب سے مقبول غلط پہلا قدم ہے۔ WSL2 کے پاس بالکل یہی علامت پیدا کرنے کے دو خودمختار طریقے ہیں، اور دونوں کو مختلف مرمت درکار ہے۔
تقسیم اپنا resolver کیوں رکھتی ہے
Windows کا DNS کلائنٹ تقسیم کے اندر استعمال نہیں ہوتا۔ WSL2 آغاز پر اپنی resolver فائل بناتی ہے، جو ایک stub پتے کی طرف اشارہ کرتی ہے جو Windows معاون مجازی مشین کے لیے مجازی سوئچ پر شائع کرتا ہے۔
یہ ترتیب عام نیٹ ورک تبدیلیوں میں مستحکم رہتی ہے کیونکہ یہ ایک بار لکھی جاتی ہے اور دوبارہ استعمال ہوتی ہے۔ ترتیب اس وقت درست نہیں رہتی جب ٹنل کلائنٹ معاون مجازی مشین کے پہلے ہی شروع ہو جانے کے بعد میزبان کی اڈاپٹر فہرست دوبارہ لکھتا ہے۔
تقسیم کے اندر کوئی چیز اس تبدیلی کی نگرانی نہیں کرتی، اس لیے فائل ایسے پتے کی طرف اشارہ کرتی رہتی ہے جو اب راستے پر نہ ہو۔ اگلی تلاش پھر انتظار کرتی ہے، وقت ختم ہو جاتا ہے، یا ایسے سرور سے جواب ملتا ہے جس نے اندرونی زون کا کبھی نام نہیں سنا۔ اندر سے resolver صرف جواب دینا بند کر دیتا ہے، اور تمام نام ایک ساتھ ناکام ہو جاتے ہیں۔
پہلے دونوں طرف سے ثبوت جمع کریں
کوئی چیز بدلنے سے پہلے ریکارڈ کریں کہ تقسیم کیا دیکھتی ہے، پھر Windows کیا دیکھتا ہے۔ یہی دونوں منظر مل کر ناکامی کی نوعیتوں کو الگ کرتے ہیں۔
تقسیم کے اندر، resolver فائل، روٹنگ جدول اور ایک اندرونی اور ایک عوامی تلاش چھاپیں:
ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.comWindows پر، ہر اڈاپٹر کے DNS سرور اور میٹرک کے ساتھ IPv4 جدول کی فہرست بنائیں۔ VPN کلائنٹ عام طور پر WSL2 سب نیٹ کے لیے راستہ نصب کرتا ہے، اور اس کا میٹرک طے کرتا ہے کہ وہ ٹریفک ٹنل سے باہر جائے یا مقامی رہے۔
Get-NetAdapter | Get-DnsClientServerAddress
route print -4
روٹ میٹرک یا پرانی فائل
پہلی خرابی پرانی فائل ہے۔ resolver آغاز کے وقت کی اڈاپٹر حالت کے لیے لکھی گئی تھی، اور ٹنل نے وہ حالت بدل دی۔ اس کا stub پتہ اب ناقابل رسائی ہو سکتا ہے، یا ایسے سرور کا نام دے سکتا ہے جو اندرونی زون کے بارے میں کچھ نہیں جانتا۔
دوسری روٹنگ کا مسئلہ ہے۔ جب VPN ایسا راستہ شامل کرتا ہے جو WSL2 سب نیٹ کو ڈھکتا ہے اور میزبان کے لنک راستے سے کم میٹرک رکھتا ہے، تو معاون مجازی مشین کو بھیجے گئے پیکٹ ٹنل میں داخل ہو جاتے ہیں۔ پھر صرف DNS نہیں، ہر WSL2 سروس کا وقت ختم ہو جاتا ہے۔
فرق کرنے والا امتحان ایک سطر پر مشتمل ہے۔ اگر عوامی resolver جیسا عددی پتہ نام ناکام ہونے پر بھی ping کا جواب دے، تو راستہ سلامت ہے اور مسئلہ DNS ہے۔ یہی وہ صورت ہے جس میں resolver بدلنا مناسب ہے، اور جس میں نہیں وہ بھی واضح ہو جاتی ہے۔ اگر عددی امتحان بھی ناکام ہو، تو معاون مجازی مشین اپنا راستہ کھو چکی ہے اور کوئی resolver فائل اسے ٹھیک نہیں کرے گی۔
روٹنگ کی صورت کے لیے، ٹنل اڈاپٹر سے خودکار میٹرک ہٹائیں اور اسے WSL2 لنک راستے سے اوپر عدد دیں:
Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown
بند کرنا اہم ہے۔ میٹرک بدلنا چلتی ہوئی معاون مجازی مشین کو دوبارہ نہیں لکھتا، اس لیے تبدیلی نظر آنے سے پہلے تقسیم کو دوبارہ بنانا ضروری ہے۔
فائل کو جان بوجھ کر اپنے ہاتھ میں لیں
اگر روٹنگ درست ہے اور صرف اندرونی نام ناکام ہوتے ہیں، تو قصور resolver کا ہے اور آپ جنریٹر روک سکتے ہیں۔ یہ دیکھ بھال کے خرچ کے ساتھ جان بوجھ کر کیا گیا تبدیلی ہے، لاپرواہی سے لاگو کرنے والا حل نہیں۔
تقسیم کے اندر جنریشن بند کرنے والے نیٹ ورک حصے کے ساتھ /etc/wsl.conf بنائیں، پھر resolver فائل خود لکھیں، پہلے کارپوریٹ سرور اور پھر عوامی متبادل:
[network]
generateResolvConf = falsesearch corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9
ترتیب اہم ہے۔ عوامی resolver اندرونی نام کا جواب نہیں دے سکتا، اور متبادل صرف انٹرنیٹ تلاش کے لیے ہے۔ فائل ایک بار آپ کی ہو جائے تو کوئی اسے دوبارہ نہیں بناتا، اس لیے منتقل ہونے والا کارپوریٹ resolver ایسی رکاوٹ بن جاتا ہے جسے آپ خود نوٹ کرنا ہوگا۔
پہلے نام جانچیں، پھر پیکیج
سسٹم resolver سے ایک اندرونی اور ایک عوامی نام کی تصدیق کریں، پھر ناکام ہونے والا عمل دہرائیں۔ پیکیج منتظمین کبھی اپنا resolver استعمال کرتے ہیں، اسی لیے کام کرنے والا getent خراب تنصیب کے ساتھ بھی موجود ہو سکتا ہے۔
اگر آپ دوبارہ لکھنا خودکار بناتے ہیں، تو اسے ایک ہی نتیجہ دینے والا بنائیں: ٹنل نہ ہو تو خالی سرور فہرست لکھنے کے بجائے موجود فائل رکھیں۔
getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com
تقسیم کے اندر سے کام کرنے والی اندرونی تلاش اور کام کرنے والی عوامی تلاش ہی ریکارڈ کرنے کے قابل نتیجہ ہے۔ میزبان پر سبز VPN نشان دونوں میں سے کسی کو ثابت نہیں کرتا۔