VPN نے DNS پر قبضہ کیا اور مقامی نام توڑ دیے: فہرست درست کریں

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

فہرست جان بوجھ کر درست کریں، پھر push طریقہ کار الگ سے نمٹیں۔ راستے تیسرا موضوع ہیں اور یہاں جو درست کیا جا رہا ہے وہ وہ نہیں۔

ایپلیکیشنز اصل میں کون سی فہرست استعمال کرتی ہیں

Windows ڈائیلاگ کے دکھانے سے نہیں بلکہ انٹرفیس سطح کی ترتیبات سے حل کرتا ہے، اس لیے ہر انٹرفیس کی مؤثر فہرستوں سے شروع کریں۔ عرف دکھائے گئے نام سے زیادہ اہم ہے، کیونکہ نیچے کا ہر حکم ایک انٹرفیس سے مخاطب ہوتا ہے۔ عرف غلط ہوا تو مرمت غلط اڈاپٹر پر پڑے گی۔ یہ کام کرتا دکھے گا اگلی بار دوبارہ جڑنے تک، جب ٹنل کا اپنا اندراج واپس آ جائے گا۔

سوال یہ ہے کہ کون سے سرور آگے آئے، اور وہ مستقل اندراج کے طور پر آئے یا DHCP لیز کے طور پر۔ دونوں حقائق طے کرتے ہیں کہ آپ کے پاس کون سی مرمت دستیاب ہے۔

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

ٹنل اڈاپٹر اور طبعی اڈاپٹر کے لیے آؤٹ پٹ پڑھیں، اور ہر ایک پر ہر پتہ نوٹ کریں۔ مستقل اندراج پالیسی یا اسکرپٹ سے ہٹایا جا سکتا ہے؛ جو اندراج DHCP دیتا ہے وہ لیز سے بندھا ہے اور واپس آئے گا، جس سے آپ کی چنی ہوئی مرمت بدل جاتی ہے۔ دور کے نیٹ ورک کے نام اعلان کردہ ریزارور حل کرتا ہے، مقامی LAN کے نام طبعی اڈاپٹر، اور استفسار پہلے دیکھی جانے والی فہرست کی طرف جاتا ہے۔

دھکیلے گئے سرور ہٹائیں، یا انہیں نیچے رکھیں

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

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

اشاریہ 1 پہلے دیکھا جاتا ہے، اس لیے دھکیلے گئے پتے دستیاب رہتے ہیں مگر ہر استفسار کا طے شدہ جواب بننا بند کر دیتے ہیں۔ validate=no جھنڈا ایک رسائی جانچ چھوڑ دیتا ہے جو اکثر ناکام ہوتی ہے جب ٹنل ابھی مستحکم ہو رہا ہو، اس لیے اخراج کوڈ پر بھروسا کرنے کی بجائے show حکم سے نتیجہ کی تصدیق کریں۔

اس پر بھروسا کرنے سے پہلے دو حدود جان لینا بہتر ہے۔ Windows ان سرورز کو نہیں مٹائے گا جو DHCP کے ذریعے netsh سے آئے، اور وہ قدریں انٹرفیس کی رجسٹری کلید کے نیچے DhcpNameServer کے طور پر رہتی ہیں، اس لیے رجسٹری میں ترمیم آخری حربہ ہے جسے اگلی لیز کے بعد پھر جانچنا پڑتا ہے۔ اڈاپٹر بائنڈنگ ترتیب بھی قابلِ بھروسا درجہ بندی کا طریقہ نہیں، کیونکہ VPN کلائنٹ اپنا اندراج فہرست کے سرے پر ڈال سکتا ہے۔

push کہاں فلٹر کیا جا سکتا ہے

بہتر مرمت انتخاب کو لاگو ہونے سے پہلے ہٹا دیتی ہے۔ Community OpenVPN کلائنٹ دھکیلے گئے ہدایت کو نام سے فلٹر کر سکتا ہے، جو سرور کی ترتیب کو اچھوتا رکھتا ہے۔

pull-filter ignore "dhcp-option DNS "

آخری خالی جگہ مطابقت کا حصہ ہے اور فلٹر سرور کے پتے کی بجائے انتخاب کا نام لیتا ہے۔ اگر پروفائل میں block-outside-dns ہدایت بھی ہو، تو اسے ہٹانا نام حل کرنے کی بجائے رساؤ سے حفاظت بدلتا ہے، اس لیے دونوں ترمیمات جوڑنے کی بجائے اسے الگ سے طے کریں۔

ایک ضدی میزبان نام کے لیے Windows hosts فائل میں ایک سطر پوری مشین کے لیے ریزارور دوبارہ ترتیب دینے سے زیادہ مستحکم ہے۔ یہ اگلے شخص کو نظر بھی نہیں آتی، اس لیے جہاں مشین کی ترتیب دستاویز ہوتی ہے وہاں اسے لکھیں۔

مرمت کو دوبارہ جڑنے تک قائم رکھیں

نام حل کرنے کی جانچ دو بار کرنی ہوتی ہے، ایک بار چنے گئے سرور کے سامنے اور ایک بار اس شکل میں جو ایپلیکیشن استعمال کرتی ہے۔ یہ جوڑی ریزارور ترتیب کے مسئلے کو ایسے سرور سے الگ کرتی ہے جو بالکل جواب نہیں دیتا۔ پہلی جانچ چھوڑنے سے دونوں وجوہات الجھی رہ جاتی ہیں۔

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

ٹنل دوبارہ جوڑیں اور دونوں حکم دہرائیں۔ جو ہاتھ سے بدلا وہ اگلے کنکشن تک ہی رہتا ہے، کیونکہ کلائنٹ اڈاپٹر اٹھاتے وقت اپنی ریزارور حالت دوبارہ بناتا ہے۔ netsh سطریں اپنے کلائنٹ کی معاون کنکشن اسکرپٹ میں رکھیں، اس اسکرپٹ کو کامیابی سے ختم ہونے دیں، اور چلنے سے پہلے تھوڑا انتظار شامل کریں۔ اسکرپٹ کے بعد DNS لاگو کرنے والا کلائنٹ بہرحال نتیجہ اوپر لکھ دے گا۔

اگر مرمت کے بعد عوامی نام حل ہوں اور اندرونی نام اب بھی ناکام ہوں، تو ریزارور فہرست اب مشتبہ نہیں ہے۔ استفسار شاید سرور تک پہنچتا ہی نہیں، جو کسی اور DNS ترتیب کی بجائے روٹنگ یا فائر وال قاعدے کی طرف اشارہ کرتا ہے۔ انٹرفیس کا عرف اور وہ پتے نوٹ کریں جن پر آپ جمے، کیونکہ دونوں مشینوں کے درمیان مختلف ہوتے ہیں اور کوئی بھی اکیلا دوبارہ تعمیر میں نہیں ٹکتا۔