WSL 2 میں resolv.conf: VPN منسلک ہوتے ہی DNS بند ہو جاتا ہے

ڈسٹری بیوشن کے اندر براؤزنگ کام کرتی ہے، اور سرنگ اوپر آتے ہی پہلا داخلی ہوسٹ نام ناکام ہو جاتا ہے۔ فطری ردِعمل یہ ہے کہ کوئی عوامی حل کنندہ شامل کیا جائے، جو انٹرنیٹ واپس لاتا ہے اور باقی دن کے لیے کارپوریٹ نام ناقابلِ رسائی بنا دیتا ہے۔ WSL 2 میں، /etc/resolv.conf کنفیگریشن نہیں بلکہ تیار شدہ آؤٹ پٹ ہے، اور سمجھنے کے قابل طریقہ کار یہی ہے۔ حل بہتر حل کنندہ نہیں، فائل کی ملکیت ہے۔

فائل بنتی ہے، کنفیگر نہیں ہوتی

WSL 2 فائل کو آغاز پر اُس وقت نظر آنے والے Windows اڈاپٹروں سے لکھتا ہے، اور اوپر ایسی تبصرہ چھاپتا ہے جو یہ بتاتی ہے۔ بعد میں جب VPN کلائنٹ کوئی اڈاپٹر شامل کرتا یا دوبارہ لکھتا ہے، ڈسٹری بیوشن لازمًا کچھ دوبارہ نہیں بناتا، اور فائل ایسے نیٹ ورک کی وضاحت کرتی رہتی ہے جو اب موجود نہیں۔

ناکامی کا دوسرا طریقہ زیادہ خاموش ہے: WSL صرف کچھ اڈاپٹروں سے سرور نقل کر سکتا ہے۔ اگر طبعی اڈاپٹر میں پہلے ہی IPv6 حل کنندہ موجود ہو، تو VPN اڈاپٹر کے فراہم کردہ IPv4 سرور شامل کرنے کے بجائے خارج کیے جا سکتے ہیں، اور فائل مکمل دکھائی دیتی ہے جبکہ وہی سرور چھوڑ دیتی ہے جو داخلی ناموں کا جواب دیتا ہے۔

Windows کے منظر کا Linux کے منظر سے موازنہ کریں

ترمیم سے پہلے دونوں اطراف پڑھیں۔ ڈسٹری بیوشن کے اندر دیکھیں کہ فائل میں کیا ہے اور یہ عام فائل ہے یا لنک۔ Windows پر ہر اڈاپٹر کا حل کنندہ فہرست کریں، بشمول وہ جو VPN نے بنایا:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

جب VPN اڈاپٹر کارپوریٹ سرور دکھاتا ہے اور Linux کچھ اور، تو فرق رسائی میں نہیں بلکہ تیاری میں ہے۔ اڈاپٹروں کی فہرست اور پتے دونوں موازنہ کریں، کیونکہ غائب اڈاپٹر غائب سرور کی وضاحت کرتا ہے۔ یہی فرق طے کرتا ہے کہ آپ WSL ٹھیک کر رہے ہیں یا فائر وال، اور دونوں میں کچھ بھی مشترک نہیں۔

تیاری بند کریں اور اپنی فائل لکھیں

ایک دستاویزی ترتیب WSL کو فائل دوبارہ لکھنے سے روکتی ہے، اور وہ /etc/wsl.conf میں ہے۔ اُس فائل میں نیٹ ورک کا حصہ شامل کریں:

[network]
generateResolvConf = false

پھر Windows سے wsl --shutdown کے ساتھ ڈسٹری بیوشن بند کریں اور دوبارہ چلائیں۔ اگر راستہ عام فائل نہ ہو کر علامتی لنک ہو، تو اپنا مواد لکھنے سے پہلے لنک ہٹا دیں، کیونکہ لنک کے ذریعے لکھنا اگلی بار آغاز پر تیار شدہ ہدف دوبارہ بنا سکتا ہے۔ اُس لمحے سے فائل آپ کی ہے اور کوئی اُسے دوبارہ نہیں لکھتا۔

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

تلاش کے ڈومین کے بغیر، نامکمل ہوسٹ نام عوامی جڑ کے ساتھ مکمل ہوتا ہے اور ‘ایسا کوئی ڈومین نہیں’ کے طور پر واپس آتا ہے۔ timeout مردہ پہلے سرور کو ہر تلاش روکنے سے باز رکھتا ہے، attempts محدود کرتا ہے کہ ایک تلاش کتنی کوششیں خرچ کرے، اور rotate دوبارہ کوششوں کو ہمیشہ اوپر سے شروع کرنے کے بجائے پھیلاتا ہے۔ سودا یہ ہے کہ فائل اب ایسے VPN کی پیروی نہیں کرتی جس کا حل کنندہ پتہ سیشنوں کے درمیان بدلتا ہے۔

بدلتے حل کنندہ سے نمٹیں، پھر تصدیق کریں

بعض کلائنٹ سیشن کے لیے مخصوص حل کنندہ دیتے ہیں، اس لیے جامد فائل اگلے کنکشن پر ٹوٹ جاتی ہے۔ دو طریقے قابلِ دفاع ہیں۔ جب بھی پتہ بدلے چھوٹی اسکرپٹ سے فائل لکھیں، یا تیاری جاری رکھیں اور یقینی بنائیں کہ WSL جس اڈاپٹر سے نقل کرتا ہے وہ کارپوریٹ سرور رکھتا ہے۔ دوسرے کو ہک کی ضرورت نہیں اور جب تیاری VPN اڈاپٹر چھوڑ دے تو ناکام ہوتا ہے؛ دونوں کو پھر بھی پہلے IPv6 تصادم حل کرنا لازم ہے۔

Windows اپنی نام پالیسیاں بھی نافذ کرتا ہے، جیسے لاحقہ تلاش کی فہرست یا مخصوص ڈومینوں کے لیے حل کی پالیسی، اور اڈاپٹروں کے پتے نقل کرنے سے وہ قواعد دوبارہ نہیں بنتے۔ اگر کوئی نام Windows پر حل ہو اور اُسی سرور کے ساتھ ڈسٹری بیوشن میں نہ ہو، تو سرنگ کو قصوروار ٹھہرانے سے پہلے لاحقوں کے سلوک کا موازنہ کریں۔

پیکٹ سے نہیں، نام سے جانچیں: getent hosts sensor-access0.corp.example حل کنندہ کے اسٹیک سے گزرتا ہے، جبکہ ping کسی محفوظ یا لفظی پتے کے خلاف کامیاب ہو سکتا ہے۔ پھر کنکشن منقطع اور دوبارہ منسلک کرنے کے بعد دہرائیں، کیونکہ جو ترتیب ایک بار کام کرے اور دوبارہ شروع ہونے پر دوبارہ بنے وہ کبھی درست نہیں ہوئی۔ سابقہ مواد محفوظ کریں اور نوٹ کریں کہ اُس مشین پر راستہ کس جزو کی ملکیت ہے، تاکہ اگلی تبدیلی ثبوت کے ساتھ شروع ہو۔