VPN کا DNS کام کرتا ہے، لیکن .local نام اب بھی ناکام ہوتے ہیں: انہیں کون حل کرتا ہے؟

ایک ہی VPN پر دو مشینیں، ایک ہی ہوسٹ نام، اور ان میں سے صرف ایک اسے حل کرتی ہے: فرق عام طور پر سرنگ نہیں بلکہ یہ ہے کہ کس حل کنندہ نے جواب دیا۔ Linux ڈیسک ٹاپ پر وہ نام نام سروس سوئچ سے، systemd-resolved کے اسٹب سے، یا ایسے حل کنندہ سے گزر سکتا ہے جو ایپلیکیشن خود لائی ہو، اور ان میں سے ہر ایک اسی لاحقے پر اپنا اصول لاگو کرتا ہے۔ اصول اسی لاحقے پر الگ ہوتے ہیں، کیونکہ .local غیر جانبدار لیبل نہیں ہے۔ کسی چیز کے چلنے کی ترتیب بدلنے سے پہلے معلوم کریں کہ ناکام پروگرام واقعی کون سا راستہ لیتا ہے۔

دو حل کنندہ، دو مختلف جوابات

روایتی glibc تلاش nsswitch.conf کی hosts: سطر سے گزرتی ہے اور ایک کے جواب دینے تک ہر ماڈیول سے باری باری پوچھتی ہے۔ اسٹب سننے والے کے ذریعے systemd-resolved سے بات کرنے والا کلائنٹ اس کے بجائے ایک ہی عمل سے پوچھتا ہے، اور وہ عمل ہر رابطے کے لیے پالیسی کے ساتھ اپنے خاص معاملات بھی لاگو کرتا ہے۔ جو ایپلیکیشن اپنا حل کنندہ لاتی ہے، یا ایسی لائبریری منسلک کرتی ہے جو یہ کرتی ہے، وہ دونوں سے گزر سکتی ہے۔ اس لیے ایک ہوسٹ نام کے ایک مشین پر تین مالک ہو سکتے ہیں، اور ان میں سے صرف ایک جانتا ہے کہ VPN کا کیا ارادہ تھا۔

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

کون سے حکم نے واقعی آپ کے حل کنندہ سے پوچھا

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

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

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

کیوں .local آپ کے unicast زون کو نظر انداز کرتا ہے

systemd-resolved کا حوالہ بتاتا ہے کہ .local پر ختم ہونے والے کثیر لیبل نام، mDNS فعال ہونے پر عام unicast DNS کے بجائے عام طور پر multicast DNS پر جاتے ہیں۔ RFC 6762 اس نام کی جگہ کو link-local multicast کے لیے مخصوص رکھتا ہے، اس لیے کوئی کارپوریٹ زون درست ریکارڈ رکھ سکتا ہے جس کے بارے میں اس لاحقے کے لیے کبھی نہیں پوچھا جاتا۔ سرنگ حل کنندہ کو بہترین طریقے سے روٹ کر سکتی ہے اور پھر بھی دوڑ ہار سکتی ہے۔ کیش سے کامیاب ping اس تلاش کے بارے میں کچھ نہیں بتاتا جو ابھی ہوئی ہے۔

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

تنگ استثنا عالمی دوبارہ ترتیب کو ہرا دیتا ہے

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

یہ منقطع ہونے کے بعد بھی برقرار رہتا ہے، کیونکہ رابطہ واپس آنے پر رابطہ پالیسی دوبارہ لاگو ہوتی ہے۔ مشترکہ nsswitch.conf میں ترمیم کرنا پرکشش اور زیادہ مہنگا متبادل ہے، کیونکہ یہ مشین پر ہر نام کے لیے تلاش کا رویہ بدل دیتا ہے، بشمول مقامی دریافت۔ multicast ڈیمن کو غیر فعال کرنا بھی مساوی نہیں: یہ مقامی رویہ ہٹاتا ہے لیکن کسی بھی حل کنندہ کو کارپوریٹ زون نہیں سکھاتا۔ اگر سروس نئی ہے اور وراثت میں نہیں ملی، تو اسے اپنی تنظیم کے کنٹرول والے ذیلی ڈومین کے تحت رکھیں اور مقابلہ مکمل طور پر چھوڑ دیں۔ جب نام فرم ویئر میں مقرر ہو یا لیبل پر چھپا ہو تو تنگ استثنا منتخب کریں، اور جب آپ اب بھی کلائنٹ کنٹرول کرتے ہیں تو نیا ذیلی ڈومین منتخب کریں۔

تبدیلی کے بعد کیا ثابت کرنا ہے

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

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

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