dnsmasq میں آپ کا VPN ڈومین زون ٹرانسفر نہیں ہے

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

کلائنٹ نے جو قبول کیا وہ وہ نہیں جو گیٹ وے نے پیش کیا

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

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

ڈومین اندراج کی دو قسمیں

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

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

resolv.conf میں localhost کوئی خامی نہیں

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

اس اندراج کو عوامی resolver سے بدلنا کلاسیکی غلط اصلاح ہے۔ یہ عوامی نام حل بحال کرتا ہے اور اسی ترمیم میں مشروط پالیسی کو ترک کر دیتا ہے۔

backends کو نہ ملائیں

زیرِ انتظام dnsmasq مثال اور سسٹم resolver مختلف کنفیگریشن اور مختلف حالت کے مناظر والے مختلف پروگرام ہیں۔ ایک کے لیے حالت کا حکم دوسرے کے بارے میں کوئی مفید بات نہیں بتاتا۔

مشخص کریں کہ منتظم کون سا backend استعمال کرنے کے لیے کنفیگر ہے، پھر اس backend کی تیار کردہ کنفیگریشن پڑھیں، نہ کہ اتفاقاً موجود کوئی ڈسٹری بیوشن بھر کی فائل۔ منتظم اپنی مثال کی کنفیگریشن لکھتا ہے اور اس مثال کے لیے حسبِ ضرورت اختیارات کی حمایت کرتا ہے، اس لیے غیر متعلق عالمی فائل میں ترمیم کچھ نہیں بدلتی اور بےاثر تبدیلی لگتی ہے۔ پورٹ 53 پر دوسرا ڈیمن شروع کرنا بیکار سے بھی بدتر ہے، کیونکہ اب دو پروگرام پورٹ کی ملکیت پر متفق نہیں۔ پہلے مالک کا تعین کریں، پھر وہاں ترمیم کریں جہاں وہ مالک پڑھتا ہے۔

نام کی جگہ کی جانچ کریں، صرف جواب کی نہیں

ایپلیکیشن کے معمول کے راستے سے ایک مجاز نجی نام اور ایک عوامی کنٹرول نام پوچھیں۔ کارپوریٹ سرور پر براہِ راست سوال ثابت کرتا ہے کہ ریکارڈ موجود ہے؛ یہ ثابت نہیں کرتا کہ کلائنٹ نے وہ سرور منتخب کیا۔ دوسرا سوال ہی پالیسی کی جانچ کرتا ہے۔

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