VPN کے ساتھ مقامی ڈومین کے لیے macOS ریزولور فائل
ایک تنگ ریزولور فائل Mac پر ایک مقامی ڈومین کو اس کے اپنے DNS سرور تک بھیج سکتی ہے، کام کے VPN کا ریزولور بدلے یا کوئی راستہ بنائے بغیر۔
آپ کا کام والا VPN کمپنی کے نام بخوبی حل کرتا ہے جبکہ گھر کا پرنٹر نام سے ناقابلِ رسائی رہتا ہے، اور لوگ عام طور پر جس حل کی طرف جاتے ہیں وہ پورے Mac کو گھر کے راؤٹر کی طرف موڑنا ہے۔ یہ مسئلے کی ضرورت سے کہیں بڑی تبدیلی ہے۔ macOS ایک چھوٹی ریزولور فائل کے ذریعے ایک ہی DNS لاحقہ اپنے سرور کو بھیج سکتا ہے اور ہر دوسری تلاش کو بالکل وہیں چھوڑ سکتا ہے جہاں وہ تھی۔
اجازت کی حد پہلے آتی ہے: یہ اس ڈومین کے لیے ہے جس کا آپ انتظام کرتے ہیں یا جسے ترتیب دینے کا آپ کو اختیار دیا گیا ہے۔ یہ کسی ادارے کی نافذ کردہ DNS پالیسی یا اس کی مقامی نیٹ ورک پابندیوں کو بائی پاس کرنے کا راستہ نہیں ہے۔
تنگ کام والی ایک فائل
فرض کریں مقامی زون lab.example.org ہے اور اس کا سرور 192.168.55.1 پر جواب دیتا ہے۔ جس Mac پر آپ کو تبدیلی کی اجازت ہے، وہاں منتظم ایک سادہ متنی فائل بناتا ہے جس کا نام خود ڈومین ہے، /etc/resolver/lab.example.org، جس میں صرف ایک nameserver 192.168.55.1 سطر ہوتی ہے۔ یہ فولڈر نئے سسٹم پر نہ ہو تو منتظم کے حقوق سے بنائیں، اور لکھنے سے پہلے دیکھ لیں کہ انتظامی سافٹ ویئر کے پاس پہلے سے وہاں فائل نہ ہو۔
Apple کی ریزولور ترتیب کی دستاویزات اس روایت کی وضاحت کرتی ہیں کہ جب فائل کے اندر ڈومین کی الگ ترتیب موجود نہ ہو تو فائل کا نام ہی ڈومین فراہم کرتا ہے۔ یہی نام رکھنے کا اصول پوری ترکیب ہے، اور اسی لیے فائل کو سرور کے نام پر نہیں بلکہ زون کے نام پر ہونا چاہیے۔
macOS ریزولورز میں سے کیسے چنتا ہے
ایک سے زیادہ ریزولور کلائنٹ فعال ہو سکتے ہیں، اور سب سے مخصوص مماثل ڈومین جیتتا ہے۔ اس لیے lab.example.org کے لیے ریزولور کا دائرہ طے شدہ ریزولور سے مختلف ہے، اور اپنی فائل والا زیادہ مخصوص ذیلی ڈومین پھر فوقیت لے سکتا ہے۔ یہی چیز کام کے VPN کو اپنا لاحقہ رکھنے دیتی ہے جبکہ آپ کا لیب زون کہیں اور جاتا ہے۔ اس ترتیب میں کوئی چیز عالمی نہیں، اور یہی یاد رکھنے والی بات ہے۔
/etc/resolv.conf کو چھوڑ دیں۔ macOS یہ فائل خود لکھتا ہے، اور اس میں کبھی ڈومین کے لیے مخصوص حل کی پوری تصویر نہیں تھی۔ ترتیب اس فولڈر کی فائلوں کے بجائے سسٹم کنفیگریشن ڈیٹا بیس سے بھی آ سکتی ہے، اور اسی لیے انتظامی پروفائل آپ کی لکھی ہوئی چیز کو منسوخ کر سکتا ہے۔
تین چیزیں جو فائل فراہم نہیں کر سکتی
سرور قابلِ رسائی ہونا چاہیے۔ اگر VPN مقامی نیٹ ورکنگ کو روکتا ہے، یا کوئی کارپوریٹ راستہ سرور کے پتے کی حد پکڑ لیتا ہے، تو بالکل درست لاحقہ فائل بھی استفسار نہیں پہنچا سکتی۔ یہ معاملہ نیٹ ورک کے مالک کے پاس لے جائیں، خود مقامی استثنائیں وسیع نہ کریں۔
زون میں درست جواب ہونا چاہیے، اور اسے printer.lab.example.org جیسے مکمل طور پر اہل نام سے جانچنا بہتر ہے۔ مختصر نام تلاش ڈومین کا رویہ ابھار سکتا ہے اور آخر میں آپ کے مطلوبہ سوال سے مختلف سوال پوچھ بیٹھ سکتا ہے۔
آخر میں، ایپلیکیشن کو وہ جواب استعمال کرنے کے قابل ہونا چاہیے۔ پرنٹر کا نام حل کرنا اس کے پتے تک رسائی نہیں دیتا، اور اس کے پیچھے کی سروس نہیں کھولتا۔ واپس آیا پتہ اب بھی اجازت شدہ راستہ اور رسائی کی وہ پالیسی چاہتا ہے جو رابطے کی اجازت دے۔ ریزولور فائل بدلتی ہے کہ نام کہاں تلاش ہوتا ہے؛ یہ نتیجے کے لیے راستہ محفوظ نہیں کرتی۔
DNS بدلنے کے بجائے انتخاب کی تصدیق کریں
دیکھیں macOS اس وقت واقعی کیا استعمال کر رہا ہے، اور مکمل اہل نام ایپلیکیشن کے اندر سے یا ایسی چیز سے پوچھیں جو ایپلیکیشنز کی طرح حل کرے۔ 192.168.55.1 پر براہِ راست استفسار ثابت کرتا ہے کہ سرور جواب دیتا ہے؛ یہ ثابت نہیں کرتا کہ macOS نے عام تلاشوں کے لیے وہی سرور چنا۔ یہ مختلف حقائق ہیں، اور صرف دوسرا بتاتا ہے کہ آپ کا براؤزر کیا تجربہ کرے گا۔
اگر کوئی دوسرا ریزولور پہلے ہی اسی لاحقے کا دعویٰ کرتا ہے، تو ترجیحی اشارے شامل کرنے سے پہلے معلوم کریں کہ وہ کس کا ہے۔ دستاویزی search_order ترتیب ان کلائنٹس کو ترتیب دیتی ہے جو ایک ہی ڈومین بانٹتے ہیں؛ یہ کوئی عالمی ترجیحی سوئچ نہیں جو عام ریزولور کو ہر استفسار میں جیتا دے۔
تصدیق کریں کہ VPN منسلک ہونے پر کمپنی کے نام اب بھی حل ہوتے ہیں، پھر فائل اور اس کا مقصد اپنے مقامی نوٹس میں درج کریں۔ جب یہ ترتیب ختم ہو، تو نیٹ ورک کی تمام DNS ترتیبات دوبارہ مقرر کرنے کے بجائے صرف وہی فائل حذف کریں اور دونوں نام کی جگہیں دوبارہ جانچیں۔