تقسیم شدہ DNS اور VPN: ڈومین قواعد IP راستے نہیں ہیں
تقسیم شدہ DNS نام کے مطابق resolver چنتا ہے، اور جواب کو اب بھی راستہ چاہیے۔ ڈومین قاعدہ اور راستہ الگ الگ جانچیں، اسی پلیٹ فارم پر جو آپ واقعی چلاتے ہیں۔
آپ کا لیپ ٹاپ intranet.corp کو ٹنل کے ذریعے حل کرتا ہے جبکہ gitlab.com سروس فراہم کنندہ کے resolver کی طرف جاتا رہتا ہے، اور یہی وہ ترتیب ہے جو ڈیزائن کے مطابق کام کرتی ہے۔ دو الگ فیصلوں نے اسے بنایا: نام کی مطابقت کا قاعدہ resolver چنتا ہے، اور راستہ جواب واپس لاتا ہے۔ ان میں سے کوئی بھی توڑیں اور براؤزر وہ ناکامی دکھاتا ہے جو باہر سے یکساں نظر آتی ہے۔ تقسیم شدہ DNS کی بیشتر رپورٹیں دوسری ناکامی بیان کرتی ہیں اور ساتھ پہلی کے بارے میں شواہد نقل کرتی ہیں۔
دونوں نصف مختلف جگہوں پر رہتے ہیں اور عام طور پر مختلف لوگ انہیں ترمیم کرتے ہیں۔ ایک VPN پروفائل سے منسلک DNS پالیسی ہے، دوسرا وہ راستہ ہے جو ٹنل نصب کرتا ہے یا روک رکھتا ہے۔ جب کوئی طے نہ کرے کہ اصل میں کون سا نصف ہلا، ڈیبگنگ رک جاتی ہے۔
ایک درخواست میں چھپے دو فیصلے
نام کا نصف پالیسی آبجیکٹ ہے، راستہ نہیں۔ Windows پر یہ VPN پروفائل پر نام حل کرنے کی پالیسی ہے؛ Apple پلیٹ فارمز پر DNS ترتیبات کے آبجیکٹ پر مماثل ڈومینز کا مجموعہ؛ Linux پر روٹنگ ڈومین، تقسیم شدہ resolver کی سطر یا نام سروس سوئچ کی ترتیب۔ راستے کا نصف عام روٹنگ ہے، جو ٹنل یا ہاتھ سے نصب ہوتی ہے، اور اسے معلوم نہیں کہ ہوسٹ نام کیا ہے۔ جو پروفائل لاحقہ قبول کرتا ہے وہ صرف یہ طے کرتا ہے کہ کون جواب دے گا؛ یہ جواب کو کبھی قابل رسائی نہیں بناتا۔
ایک تیز علامتی جانچ انہیں الگ کرتی ہے: نام کی جگہ پتہ رکھیں۔ اگر پتہ کام کرے تو راستہ درست ہے اور قاعدہ غلط۔ اگر پتہ بھی ناکام ہو تو قاعدہ درست اور راستہ غائب ہو سکتا ہے۔
ہر پلیٹ فارم وہی نام قاعدہ کیسے بیان کرتا ہے
مقصود یکساں ہے اور فیلڈ کے نام نہیں۔ ایک کلائنٹ سے دوسرے میں نقل شدہ مثال صاف طور پر پارس ہوتی ہے اور کبھی مماثل نہیں ہوتی۔ تین شکلیں ایسی دکھتی ہیں:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
مماثلت یا روٹنگ ڈومین لاحقے کی جانچ ہے، اس لیے intranet.corp، git.intranet.corp کو محیط ہے اور corp.intranet کو محیط نہیں، اور اسے الٹا کرنا پوری ترتیب میں سب سے عام غلطی ہے۔ Windows نقشہ کو پروفائل سے منسلک نام حل کرنے کی پالیسی کے طور پر رکھتا ہے، انٹرفیس کے پاس پہلے سے موجود کسی بھی لاحقہ فہرست کے مقابلے میں اپنی ترجیحی ترتیب کے ساتھ۔ Apple پلیٹ فارمز مماثل ڈومینز کو نیٹ ورک ایکسٹینشن کے DNS ترتیبات کے آبجیکٹ سے منسلک کرتے ہیں، اور سسٹم انہیں ہر محدود resolver پر لاگو کرتا ہے۔ ان میں سے کوئی شکل راستہ نہیں ہے، اور کوئی بھی ناقابل رسائی پتے کو قابل رسائی نہیں بنا سکتی۔ Windows نام حل کرنے کی پالیسی حوالہ اس پلیٹ فارم کے فیلڈ نام اور ترجیحی قواعد کی فہرست دیتا ہے، اور وہ وہی قواعد نہیں جو Apple یا systemd کی دستاویزات استعمال کرتی ہیں۔
درست جواب کو اب بھی راستہ چاہیے
resolver کا جواب صرف ایک پتہ ہے، اور ایپلی کیشن کو اب بھی وہاں پہنچنا ہے۔ تقسیم شدہ ٹنل کا ڈیزائن اکثر 10.20.0.0/16 کو دھکیلتا ہے اور ڈیفالٹ راستہ روک لیتا ہے، اس لیے اندرونی نام حل ہو جاتا ہے اور پھر کنکشن لٹک جاتا ہے۔ الٹ حالت بھی اتنی ہی عام ہے: راستہ موجود ہے، عوامی resolver نجی نام کو NXDOMAIN کے ساتھ جواب دیتا ہے، اور ناکامی روٹنگ مسئلے کے طور پر درج ہوتی ہے۔ پہلے راستہ جانچنا آپ کو ایسے نام کے راستوں کو دیکھتے رہنے پر مجبور کرتا ہے جو کبھی حل نہ ہوتا۔
ایک تیسرا دروازہ بھی ہے جسے کوئی نصف محیط نہیں۔ گیٹ وے پر ACL، فائر وال قاعدہ یا کلائنٹ کی طرف کی پالیسی دونوں فیصلے درست ہونے کے بعد بھی کنکشن گرا سکتی ہے۔ جب نام حل ہو جائے، راستہ موجود ہو اور کنکشن پھر بھی وقت ختم کرے، تو DNS جانچنا بند کریں۔
نام اور راستے مقررہ ترتیب میں جانچنا
ایک ترتیب چنیں اور اسے پکڑے رہیں، ورنہ آپ اس مرحلے کے پیچھے بھاگیں گے جو آخری بار ناکام ہوا۔ دستاویزی مکمل اندرونی نام حل کریں، تصدیق کریں کہ جواب وہ پتہ ہے جو روٹنگ جدول اٹھا سکتی ہے، پھر عوامی نام کے ساتھ دہرائیں تاکہ ثابت ہو کہ ٹنل نے سب کچھ نہیں پکڑا۔ systemd ہوسٹ پر استفسار اور resolver کا روٹنگ ڈومین ایک کمانڈ کے فاصلے پر ہیں:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows کلائنٹ وہی دو سوال مختلف cmdlet کے ساتھ پوچھتا ہے۔ دوسرا وہ انٹرفیس بتاتا ہے جو سسٹم واقعی استعمال کرتا:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10اگر تلاش پتہ لوٹائے اور راستے کی جانچ جسمانی انٹرفیس کا نام لے، تو نام کا قاعدہ کام کر گیا اور راستہ نہیں۔ اگر مختصر نام ناکام ہو جبکہ مکمل نام حل ہو، تو لاحقہ فہرست غلط ہے، resolver نہیں۔
موازنہ عام طور پر کہاں غلط ہوتا ہے
پہلی غلطی یہ ہے کہ غیر متعلقہ عوامی resolver سے نجی نام کے بارے میں پوچھا جائے اور انکار کو VPN کے بارے میں ثبوت سمجھا جائے۔ دوسری یہ کہ کام کرنے والی عوامی تلاش ٹنل کے resolver راستے کو ثابت کرتی ہے، یہ مان لیا جائے۔ تیسری یہ کہ تقسیم شدہ ٹنلنگ اور تقسیم شدہ DNS کو ایک ہی ڈیزائن فیصلہ سمجھا جائے، جبکہ تعیناتی ایک میں درست اور دوسرے میں خراب ہو سکتی ہے۔ ہر غلطی ایسی جانچ سے پختہ نتائج دیتی ہے جس نے کبھی ملزوم حصے کی مشق نہیں کی۔
اپنی محفوظ DNS رکھنے والا براؤزر بھی سسٹم قاعدہ کو نظرانداز کر سکتا ہے، اسی لیے ایک براؤزر کا ناکام ہونا جبکہ دوسرے کا کامیاب ہونا تضاد نہیں۔ جواب دینے والے resolver کا موازنہ کریں، شکایت کرنے والے براؤزر کا نہیں۔
جب دونوں نصف نظر آ جائیں تو باقی سوال تکنیکی نہیں، پالیسی کا ہے: کون سی نام کی جگہیں تنظیم کی ہیں، ہر جواب کا مالک کون ہے، اور ان میں سے کون سی مشین سے بالکل نکلنی چاہئیں۔ یہ پروفائل کے پاس لکھیں، کیونکہ قاعدے کو چھونے والے اگلے شخص کو اس کی ضرورت ہوگی۔