اندرونی نام VPN پر ناکام رہتے ہیں جبکہ عوامی سائٹیں ٹھیک کھلتی ہیں

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

دو علامات جو ایک خرابی نہیں ہیں

کسی اندرونی نام کو حل نہ کر پانا اس بات کا مطلب ہے کہ سوال ایسی جگہ گیا جہاں اس کا کوئی جواب نہیں۔ استفسارات کا سرنگ سے باہر جانا اس بات کا مطلب ہے کہ سوال غلط جگہ گیا، چاہے جواب موجود تھا۔ یہ متضاد خرابیاں ہیں: ایک میں جواب غائب ہے، دوسری میں ایک زائد منزل ہے۔

پھندا یہ ہے کہ دفتری حل کنندہ ہر جگہ شامل کرنے سے پہلی خرابی دور ہو جاتی ہے اور دوسری یقینی بن جاتی ہے۔ عوامی حل کنندہ ہر جگہ شامل کرنے سے معاملہ الٹا ہو جاتا ہے۔

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

سوال کس اڈاپٹر کا حل کنندہ وصول کرتا ہے

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

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

کام کرنے والی مشین کا ipconfig /all لیپ ٹاپ والے کے برابر رکھیں، دونوں تب لیے گئے جب سرنگ قائم ہو۔ کام کرنے والی مشین اپنے دفتری اڈاپٹر پر کنکشن کے مخصوص DNS لاحقہ دکھائے گی، جبکہ لیپ ٹاپ سرنگ پر کچھ بھی نہ دکھا سکتا ہے۔ یہ فرق ”سرور بالکل وہیں ہے اور نام پھر بھی ناکام“ جیسی رپورٹوں کی پوری قسم کی وضاحت کرتا ہے، کیونکہ لاحقے کے بغیر مختصر نام کبھی اُس زون تک مکمل نہیں ہوتا جس کی خدمت دفتری حل کنندہ کرتا ہے۔

مختصر نام کو راستے سے پہلے لاحقے کی ضرورت ہوتی ہے

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

کام کرنے والی مشین کا لاحقہ DNS ٹیب پر VPN اڈاپٹر کی IPv4 خصوصیات میں نقل کریں، پھر دوبارہ جڑیں۔ لینکس پر اس کا متبادل سرنگ لنک کا سرچ ڈومین ہے، جسے systemd-resolved عالمی طور پر نہیں بلکہ فی لنک ظاہر کرتا ہے۔

دونوں ترتیبات کو اپنے نوٹس میں الگ رکھیں۔ لاحقہ تبدیل کرتا ہے کہ کیا پوچھا جاتا ہے؛ حل کنندہ کا پتہ تبدیل کرتا ہے کہ کس سے پوچھا جاتا ہے۔ ایک کو درست کرنا جب دوسرا غلط ہو، بظاہر بے ترتیب نتیجہ دیتا ہے۔

پہلے حل کنندہ سے پوچھیں، پھر نام سے

دفتری حل کنندہ سے براہ راست استفسار نام کے مسئلے کو راستے کے مسئلے سے الگ کرتا ہے، کیونکہ یہ کلائنٹ کے حل کنندہ کے انتخاب کو مکمل طور پر نظر انداز کرتا ہے۔

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

لینکس پر، وہ VPN کلائنٹ جو /etc/resolv.conf کو دوبارہ لکھتا ہے، مقامی حل کنندگان کو مکمل طور پر بدل دیتا ہے۔ vpnc اسے روکنے کے لیے DNSUpdate no مہیا کرتا ہے، اور systemd-resolved صرف درج شدہ ڈومینز کو سرنگ لنک کی طرف بھیج سکتا ہے۔ دونوں طریقے عوامی نام مقامی حل کنندہ پر رکھتے ہوئے اندرونی نام دفتر بھیجتے ہیں۔

لیک ایک چیک باکس نہیں، ایک قاعدہ ہے

نام کی حل پذیری پورٹ 53 پر UDP کا تبادلہ ہے، اس لیے وہ سرنگ جو ویب ٹریفک لے جاتی ہے مگر UDP نہیں، استفسار کو فزیکل راستے پر چھوڑ دیتی ہے۔ اسے یوں ثابت کریں کہ عوامی نام حل ہوتے وقت فزیکل نیٹ ورک کارڈ پر کیپچر کریں۔ اُس انٹرفیس پر قابلِ خواندگی شکل میں نظر آنے والا استفسار بتاتا ہے کہ سرنگ اُسے نہیں لے جا رہی۔

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

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

یہ آخری حصہ جتنا دکھتا ہے اُس سے زیادہ اہم ہے۔ OpenVPN کو route-nopull کے ساتھ شروع کریں تو بھیجا گیا DNS آپشن راستوں کے ساتھ غائب ہو جاتا ہے، الا یہ کہ پل فلٹر کو اُسے رکھنے کے لیے وسیع کیا جائے۔ اور جو کلائنٹ dhcp-option DNS کو نظر انداز کرتا ہے وہ پہلے جو کچھ استعمال کر رہا تھا وہی کرتا رہے گا۔ سرور کی طرف کوئی بھی تبدیلی نئے سیشن کی متقاضی ہے، کیونکہ حل کنندگان کی فہرست سرنگ قائم ہوتے وقت پہنچائی جاتی ہے اور پرانا سیشن پرانی حالت دکھاتا رہتا ہے۔

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