Windows پر OpenVPN جڑنے کے بعد DNS کیوں کام کرنا بند کر دیتا ہے
پورٹ 53 کہیں نہیں پہنچتا مگر حل کنندہ اب بھی ping کا جواب دیتا ہے۔ دیکھیں کہ block-outside-dns فلٹر کر رہا ہے یا نہیں، پھر ایسا حل کنندہ دیں جہاں تک ٹنل پہنچ سکے۔
دفتر کے حل کنندہ کو ping "OpenVPN" جڑنے کے بعد بھی جواب ملتا ہے، پھر بھی ہر نام کی تلاش ناکام ہو جاتی ہے۔ پتہ قابل رسائی ہے مگر پورٹ نہیں، یہ امتزاج تب سمجھ میں آتا ہے جب آپ جانیں کہ Windows ایڈاپٹر کے حساب سے DNS فلٹر کر سکتا ہے۔ اگر پروفائل میں block-outside-dns ہو تو وہی فلٹر پہلا مشتبہ ہے اور روٹ ٹیبل دیکھنے کی غلط جگہ ہے۔ نیچے کی دو جانچیں تہوں کو سیکنڈوں میں الگ کرتی ہیں۔
قابل رسائی پتہ، مردہ پورٹ
کامیاب ping ثابت کرتا ہے کہ میزبان چل رہا ہے اور راستہ موجود ہے۔ یہ پورٹ 53 تک پہنچنے کی اجازت کے بارے میں کچھ نہیں کہتا، کیونکہ متعلقہ فلٹر دوسری تہہ میں کام کرتا ہے اور ایڈاپٹر پر منحصر ہے۔ اسی لیے وہی مشین ICMP کا جواب دے سکتی ہے اور اسی پتے پر بھیجی گئی ہر استفسار کو رد کر سکتی ہے۔ کوئی بھی ترتیب بدلنے سے پہلے دونوں جانچیں ایک ہی نشست میں چلائیں۔
ping <resolver-ip>
nslookup <name> <resolver-ip>
یہی جوڑی تشخیص ہے۔ ذیلی نیٹ کی طرف عام ٹریفک چلتی رہتی ہے مگر نام کا حل مر جاتا ہے، اور لوگ نتیجہ نکالتے ہیں کہ سرور خراب ہے یا DNS کبھی بھیجا ہی نہیں گیا۔ دونوں وضاحتوں کا پیچھا کرنا مہنگا ہے، اور شواہد کسی زیادہ تنگ جگہ کی طرف اشارہ کرتے ہیں۔ کسی ترتیب کو چھونے سے پہلے جوڑی کی تصدیق کریں۔
یہ اختیار فلٹرنگ پلیٹ فارم کا قاعدہ ہے
OpenVPN کا حوالہ block-outside-dns کو Windows Filtering Platform کی پابندی بتاتا ہے جو ایپلیکیشنز کو ٹنل سے باہر کے ایڈاپٹروں پر DNS تک پہنچنے سے روکتی ہے۔ یہ TCP اور UDP پورٹ 53 کو محیط ہے۔ چونکہ فلٹر عام فائر وال قواعد کی فہرست میں نہیں بلکہ WFP میں رہتا ہے، کہیں اور اجازت کا قاعدہ شامل کرنا نتیجہ لازمی نہیں بدلتا۔ اسی لیے DNS کی اجازت دینے کا عام مشورہ ناکام ہوتا رہتا ہے۔
ترتیب درآمد شدہ پروفائل سے یا سرور سے آ سکتی ہے، اور وہ فائل جو آپ نے آخری بار ترمیم کی "اس بات کا ثبوت نہیں کہ کلائنٹ نے کیا لوڈ کیا"۔ مؤثر ترتیب اور کنکشن لاگ ساتھ پڑھیں۔ یہ اختیار Windows کے لیے مخصوص بھی ہے، اور اسے قابلِ منتقلی سمجھنے سے ایسے مشورے ملتے ہیں جو لاگو نہیں ہوتے۔
مزید قواعد شامل کرنے کے بجائے وہ کلائنٹ جزو تلاش کریں جس کے پاس یہ پابندی ہے۔ مالک وہی چیز ہے جو اسے واقعی ہٹا سکتی ہے۔
فلٹر حل کنندہ نہیں ہے
ٹنل سے باہر ٹریفک روکنا اس کے اندر چلنے والا حل کنندہ نصب نہیں کرتا۔ یہ اختیار ایک راستہ ہٹا دیتا ہے اور ٹنل کی DNS ترتیب پروفائل بنانے والے کے سپرد کر دیتا ہے۔ جس پروفائل نے کبھی حل کنندہ نہیں بھیجا اس کے پاس اب ایک بھی نہیں۔
تین جانچیں ترتیب سے کریں۔ پہلی، ناکام ایپلیکیشن واقعی کون سا حل کنندہ استعمال کرتی ہے۔ دوسری، کیا کلائنٹ نے VPN DNS ترتیبات لاگو کیں۔ تیسری، کون سا انٹرفیس ٹریفک اس حل کنندہ تک لے جاتا ہے۔
- زیر استعمال حل کنندہ:
Resolve-DnsName -Server <resolver-ip> <name>کا موازنہ ان DNS سرورز سے کریں جوipconfig /allفہرست کرتا ہے۔ - VPN DNS لاگو: اسی
ipconfig /allآؤٹ پٹ میں ٹنل ایڈاپٹر کے DNS اندراجات دیکھیں۔ - استعمال شدہ انٹرفیس:
Find-NetRoute -RemoteIPAddress <resolver-ip>اس منزل کے لیے باہر جانے والا انٹرفیس بتاتا ہے۔
اس پالیسی کے تحت LAN حل کنندہ بناوٹ کے مطابق ناقابل رسائی ہو جاتا ہے، جبکہ دیگر LAN ٹریفک چلتی رہتی ہے۔ یہی اختیار اپنا کام کر رہا ہے۔ اگر بناوٹ کو VPN کے ذریعے DNS درکار ہو تو حل کنندہ کی رجسٹریشن اور ٹنل کا راستہ درست کریں؛ اگر مقامی استثناؤں کے ساتھ split DNS درکار ہو تو ترتیب کا مالک وہ استثنائیں معاون طریقے سے بیان کرے۔
یہ اختیار کیا محیط نہیں
پورٹ 53 پورا نام کا حل نہیں ہے۔ DNS over HTTPS اور DNS over TLS مختلف ترسیل استعمال کرتے ہیں، اور کچھ ایپلیکیشنز نظام کی ترتیبات کی پروا کیے بغیر اپنی حل کنندہ منطق چلاتی ہیں۔ اسی لیے براؤزر نام حل کر سکتا ہے جبکہ کمانڈ لائن نہیں۔
اس فرق کو تضاد نہیں بلکہ تشخیص سمجھیں۔ نظام کا حل کنندہ خراب ہے یہ طے کرنے سے پہلے دونوں کا موازنہ کریں۔
لکھتے وقت نتیجہ تنگ رکھیں۔ یہ اختیار ایک پلیٹ فارم پر ایک ترسیل محدود کرتا ہے، اور حل کے راستے کا باقی حصہ اپنے مالک والا الگ ڈیزائن سوال ہے۔
کنکشن منقطع ہونے سے پہلے اور بعد حالت دیکھیں
وہی تلاش کنکشن کے دوران چلائیں اور مالک کلائنٹ کے منقطع ہونے کے بعد دوبارہ چلائیں۔ پہلی کو ٹنل کے قائم رہنے پر بیرونی حل کنندہ کے لیے ناکام ہونا چاہیے، اور فلٹر ہٹنے پر دوسری کو کامیاب ہونا چاہیے۔ اگر منقطع ہونے کے بعد بھی ناکام ہو تو فلٹر صاف نہیں ہوا۔
ipconfig /displaydns
nslookup <name> <resolver-ip>
کلائنٹ سروس یا مشین کو دوبارہ شروع کرنا عام طور پر پرانا فلٹر صاف کر دیتا ہے۔ یہ تشخیص کی تصدیق کرتا ہے مگر مستقل درستی ثابت نہیں کرتا۔ جو دیکھا اسے درج کریں، کیونکہ منقطع ہونے سے بچ جانے والا فلٹر پھر وہی کرے گا، اور وہی ریکارڈ بگ رپورٹ کو جائز ٹھہراتا ہے۔
ان جانچوں کے بعد ہی حل کنندہ بدلنا یا فائر وال پالیسی دوبارہ بنانا معنی رکھتا ہے۔ دونوں شواہد کی حمایت سے بڑی تبدیلیاں ہیں۔