OpenVPN پر منقسم DNS: ہر آپریٹنگ سسٹم پر روٹنگ ڈومین کو کیا کرنا چاہیے

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

پہلے پالیسی کا نام رکھیں، پھر وہ پلیٹ فارم بنیادی چیز چنیں جو اسے بیان کرتی ہے۔

تین ترتیبیں جنہیں آسانی سے گڈمڈ کیا جا سکتا ہے

تلاش لاحقہ مختصر نام کو پھیلاتا ہے: جب آپ لکھتے ہیں files تو یہ بن جاتا ہے files.corp.example جب ریزالور لاحقوں کو ترتیب سے آزماتا ہے۔ روٹنگ ڈومین چنتا ہے کہ نام کی جگہ کے اندر استفسارات کا کون سا ریزالور جواب دے۔ IP راستہ صرف چنے ہوئے ریزالور کو قابل رسائی بناتا ہے۔ یہ تینوں مختلف تہوں میں رہتے ہیں، اور ایک کو دوسرے سے بدلنے سے ایسی ترتیب بنتی ہے جو درست دکھتی ہے اور کچھ حل نہیں کرتی۔

اس گڈمڈ کی ایک قیمت ہے: تلاش لاحقہ شامل کرنا ہر مختصر نام کو دفتری ریزالور پر بھیجتا ہے، بشمول وہ نام جو کہیں اور کے ہیں۔ روٹنگ ڈومین چننا غیر متعلقہ استفسارات کو مقامی ریزالور پر رکھتا ہے جبکہ پھر بھی *.corp.example سرنگ کے ذریعے بھیجتا ہے۔

Linux: صرف روٹنگ والا ڈومین، تلاش لاحقہ نہیں

systemd-resolved پر، ٹلڈے سے شروع ہونے والا ڈومین صرف روٹنگ والا ڈومین ہے، یعنی اس نام کی جگہ کے استفسارات منسلک ریزالور پر جاتے ہیں اور ساتھ ہی تلاش لاحقہ بھی نہیں بنتے۔ resolvectl domain tun0 '~corp.example' یہ مقرر کرتا ہے، اور resolvectl dns tun0 10.8.0.1 سرور کا نام بتاتا ہے۔ دونوں ترتیبیں انٹرفیس کی ہیں، اس لیے اس کے ساتھ ختم ہو جاتی ہیں۔ ٹلڈے ہی وہ حصہ ہے جو لوگ چھوڑ دیتے ہیں، اور اس کے بغیر مختصر نام دفتری ریزالور کے ذریعے حل ہونے لگتے ہیں۔

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

Windows کو نام کی جگہ کی پالیسی درکار ہے، لاحقہ نہیں

Windows منقسم DNS پالیسی کو نام حل کرنے کی پالیسی جدول میں رکھتا ہے، ایڈاپٹر کے DNS لاحقے میں نہیں۔ ایک قاعدہ نام کی جگہ کو مخصوص سرورز سے جوڑتا ہے: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1۔ صرف لاحقہ مقرر کرنا مختصر ناموں کی شکل بدلتا ہے؛ یہ استفسار کو دوسرے سرور کی طرف نہیں بھیجتا۔

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

ہر پلیٹ فارم کے لیے ایک ہی ریزالور مالک رکھیں

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

جو ایپلیکیشنز اپنا خفیہ کردہ ریزالور لاتی ہیں وہ آپریٹنگ سسٹم کی پالیسی کو مکمل نظر انداز کرتی ہیں۔ یہ ایپلیکیشن کی خصوصیت ہے، سرنگ کا نقص نہیں۔

نتیجہ جانچیں، پروفائل کا متن نہیں

ہر پلیٹ فارم پر ایک ایسا نام حل کریں جو سرنگ سے گزرنا چاہیے اور ایک جو نہیں، اور تصدیق کریں کہ کون سا سرور جواب دے۔ resolvectl query host.corp.example اور Resolve-DnsName host.corp.example دونوں جواب دینے والے سرور کی اطلاع دیتے ہیں۔ دوبارہ جڑنے کے بعد دہرائیں۔ پھر تصدیق کریں کہ سرنگ کا ریزالور اس پتے پر قابل رسائی ہے جو پروفائل بھیجتا ہے، کیونکہ ناقابل رسائی سرور کی طرف اشارہ کرنے والی درست پالیسی بھی ایسے ہی ناکام ہوتی ہے جیسے کوئی پالیسی نہ ہو۔

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