اپنے Mac پر VPN میں استعمال ہونے والے DNS حل کرنے والوں کو کیسے جانچیں

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

پتوں سے پہلے بلاک کی ترتیب پڑھیں

ہر اندراج resolver #N سے کھلتا ہے اور nameserver[0]، کبھی if_index، ایک flags سطر، reach اور جب بلاک سادہ ڈیفالٹ نہ ہو تو domain اور search domain کی فہرست دکھاتا ہے۔ بغیر ڈومین والا 1 نمبر حل کرنے والا وہ ڈیفالٹ ہے جو عوامی نام سنبھالتا ہے۔ اپنے جھنڈوں میں Scoped رکھنے والا ہر بلاک اُس انٹرفیس سے بندھا ہے جس کا نام if_index بتاتا ہے، اور Supplemental سے نشان زد ہر چیز صرف اُس کے نیچے درج ڈومینوں پر لاگو ہوتی ہے۔

انتخاب لاحقہ کا ملانا ہے۔ intranet.corp.example جیسے نام کے لیے macOS اُس حل کرنے والے کو ترجیح دیتا ہے جس کا domain اندراج سب سے طویل ملتا جلتا لاحقہ ہو، اس لیے domain : corp.example والا بلاک آؤٹ پٹ میں بہت نیچے ہونے پر بھی ڈیفالٹ کو ہرا دیتا ہے۔ ایک ہی لمبائی کے ڈومینوں کے درمیان برابری order طے کرتا ہے۔ پہلی نظر کو شاید ہی اس سے زیادہ درکار ہو: پورا آؤٹ پٹ جب آپ ایک بلاک شروع سے آخر تک پڑھنا چاہیں، ابتدائی سطریں بلاک کی ترتیب جاننے کے لیے، اور ایک چھنی ہوئی گزر جو بلاک کے سرخیوں کو خانے کی سطروں کے ساتھ چھاپے۔ محدود بلاک اپنی سرخی کے نیچے ظاہر ہوتے ہیں اور اوپر کی فہرست کے تسلسل کی طرح پڑھے جاتے ہیں، اس لیے جب بھی آؤٹ پٹ نقل کریں سرخی نگاہ میں رکھیں۔

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index کو سرنگ کے انٹرفیس سے ملا دیں

اشاریہ صرف اُس وقت کارآمد ہے جب آپ اُس کے پیچھے کا انٹرفیس نام بتا سکیں۔ scutil --nwi نظام کے پاس موجود نیٹ ورک معلومات درج کرتا ہے، بشمول بنیادی انٹرفیس اور رسائی، جبکہ ifconfig -l آپ کو نام دیتا ہے، جہاں utun0 سے utun9 تک وہ سرنگ کے امیدوار ہیں جو کلائنٹ عام طور پر بناتا ہے۔ Apple اپنی جانچ کی مثال کے طور پر scutil --dns کو تعیناتی گائیڈ میں استعمال کرتا ہے، اور دستاویز کرتا ہے کہ Network Extension منتخب ڈومینوں کو منتخب حل کرنے والوں تک کیسے بھیج سکتا ہے، اور یہی وہ طریقہ کار ہے جو وہ محدود بلاک ظاہر کرتے ہیں۔

سوال کا فیصلہ کرنے والی جانچ یہ ہے کہ حل کرنے والا اُس راستے پر ہے جو سرنگ نے نصب کیا:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

اگر route -n get ایسا گیٹ وے اور انٹرفیس واپس کرے جو حل کرنے والے کے اندراج سے نہ ملتے ہوں، تو پتہ بالکل درست ہو کر بھی ناقابل رسائی ہو سکتا ہے۔ صرف کارپوریٹ ذیلی نیٹ لے جانے والی منقسم سرنگ اُن سے باہر DNS سرور کی طرف جانے والے سوالات گرا دیتی ہے، اور ناکامی وقفہ کے طور پر ظاہر ہوتی ہے، اسی لیے ترتیب کا آؤٹ پٹ صاف دکھتا رہتا ہے۔

نظام کے حل کرنے والے سے پوچھیں، پھر سرور سے

تین اوزار تین مختلف سوالوں کا جواب دیتے ہیں، اور اِن کو ملانا اس شعبے کے بیشتر غلط نتائج پیدا کرتا ہے۔ dscacheutil -q host -a name اُسی نظام کے حل کرنے والے سے گزرتا ہے جو عام ایپلیکیشنز استعمال کرتی ہیں، اس لیے محدود اور اضافی بلاک لاگو ہوتے ہیں۔ بغیر سرور دلیل والا dig /etc/resolv.conf پڑھتا ہے، جو macOS پر محدود حل کے لیے سچ کا ماخذ نہیں ہے، اور یہ ہر ڈومین کے قواعد بالکل چھوڑ دیتا ہے۔ dig @address ٹھیک ایک سرور تک پہنچتا ہے اور انتخاب کے بارے میں کچھ نہیں بتاتا۔

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

جب پہلا حکم جواب دے اور دوسرا NXDOMAIN واپس کرے، تو آپ کو وہی تقسیم مل گئی جس کی آپ تلاش کر رہے تھے اور کچھ ٹوٹا نہیں۔ جب پہلا وقت ختم کرے جبکہ dig @10.20.0.53 جواب دے رہا ہو، تو حل کرنے والا کام کرتا ہے مگر سرنگ کے چنے راستے پر ناقابل رسائی ہے، اس لیے اگلا قدم DNS ترتیبات بدلنا نہیں بلکہ route -n get ہے۔ نجی نام ٹکٹ یا مشترکہ نوٹ میں چپکانے والی کسی چیز سے باہر رکھیں۔

آؤٹ پٹ آپ کو کیا نہیں دکھا سکتا

حل کرنے والوں کی فہرست کے اوپر یا پہلو میں کئی تہیں بیٹھی ہیں، اور ہر ایک سوال کسی ایسی جگہ بھیج سکتی ہے جس کا آؤٹ پٹ کبھی ذکر نہیں کرتا۔ محفوظ DNS والا براؤزر اپنے خفیہ کردہ چینل سے حل کر سکتا ہے، اس لیے dscacheutil کے وقت ختم ہوتے ہوئے صفحہ لوڈ ہونا تضاد نہیں۔ سلامتی کا سافٹ ویئر نصب کردہ DNS پراکسی Network Extension فراہم کنندہ کے طور پر چلتا ہے اور سوالات خود آگے بھیجتا ہے، اور scutil --dns دکھاتا ہے کہ کیا ترتیب دیا گیا، نہ کہ وہ بالا دست پتہ جو پراکسی نے آخر میں استعمال کیا۔ تلاش کے ڈومین تیسرا موڑ جوڑتے ہیں: ناقص نام میں درج ہر لاحقہ ترتیب سے جڑتا ہے، اس لیے جواب دینے والا بلاک وہ ہو سکتا ہے جس کا آپ نے کبھی گمان نہیں کیا۔

پرانے جواب خارج کرنے میں سب سے سستے اور سب سے زیادہ چھوڑے جانے والے ہیں:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

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

پہلے اور بعد کے لیے مختصر رہنما

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

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

فرق سطروں کے بجائے بلاکوں کے حساب سے پڑھیں۔ سرنگ کے انٹرفیس کا اشاریہ اور نجی لاحقے کے لیے domain اندراج رکھنے والا نیا محدود حل کرنے والا ہی متوقع شکل ہے۔ عوامی پتے کی طرف اشارہ کرنے والا نیا ڈیفالٹ حل کرنے والا ایسی دریافت ہے جسے کلائنٹ پروفائل کے مالک کے سامنے رکھنا چاہیے۔ پھر تلاش کو اُس ایپ کے اندر دہرائیں جو واقعی ناکام ہوئی، صرف شیل میں نہیں، اور نتیجے کے ساتھ route -n get کا انٹرفیس لکھیں۔

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

اس ترتیب میں چار جانچیں: کیا کوئی حل کرنے والا بلاک نام کے سب سے طویل لاحقے سے ملتا ہے؛ کیا وہ بلاک سرنگ کے نصب کردہ انٹرفیس سے بندھا ہے؛ کیا اُس کے نام سرور تک کا راستہ سرنگ استعمال کرتا ہے؛ اور کیا نظام کا حل کرنے والا، نہ کہ dig، جواب واپس کرتا ہے۔ پہلی ناکام جانچ بتاتی ہے کہ DNS پالیسی، سرنگ کے راستے یا ایپ بدلنی ہے۔ اگر چاروں گزر جائیں اور نام پھر بھی ناکام ہو، تو مسئلہ DNS سے اوپر ہے، اور اگلا جانچنے والا وہ ہے جو اُس کے سامنے پورٹ 53 پر جواب دیتا ہے۔