resolv.conf آپ کا VPN DNS کیوں دکھاتا ہے مگر تلاشیں اسے نظر انداز کرتی ہیں

لاگز میں کچھ غلط دکھائی نہیں دیتا: انٹرفیس چل رہا ہے، حل کنندہ VPN کا DNS سرور بتاتا ہے، اور ڈسک کی فائل اسے فہرست کرتی ہے۔ پھر بھی اندرونی میزبان نام مقامی راؤٹر کے ذریعے حل ہوتا ہے۔ یہ تینوں بیانات ایک دوسرے کے خلاف نہیں، کیونکہ فائل، ہر لنک کی حالت اور تلاش کا راستہ الگ الگ چیزیں ہیں جن کا نام اتفاقاً ایک ہے۔ آگے وہ راستہ ہے جو systemd-resolved والے میزبان پر کوئری واقعی طے کرتی ہے۔

resolv.conf نام کی تین چیزیں

resolved والے میزبان پر /etc/resolv.conf عام طور پر /run/systemd/resolve/stub-resolv.conf کی طرف علامتی لنک ہوتا ہے۔ اس ہدف میں مقامی stub سننے والے کا پتہ، 127.0.0.53، اور resolved کے شمار کردہ تلاش ڈومین ہوتے ہیں۔ یہ حالت کا عکس ہے، خود حالت نہیں۔

حالت resolved کی ہر لنک کے لیے ترتیب میں رہتی ہے، اسی لیے resolvectl status فائل سے اختلاف کر کے بھی درست ہو سکتا ہے۔ ہر لنک اپنے سرور اور اپنے روٹنگ ڈومین رکھتا ہے، اور کوئری آنے پر stub اسی ڈیٹا سے رجوع کرتا ہے۔ systemd-resolved کی دستی بنائی گئی فائلوں اور ہر لنک کے ماڈل کی وضاحت کرتی ہے؛ عکس اور حالت کی تقسیم ہی یاد رکھنے والا حصہ ہے۔ علامتی لنک کا ہدف بدلنے سے روایتی کلائنٹ جو پڑھتے ہیں وہ بدلتا ہے، حل کنندہ جو جانتا ہے وہ نہیں۔

تیسری چیز، /run/systemd/resolve/resolv.conf، ہر لنک کو ایک ہی سرور فہرست میں ہموار کر دیتی ہے۔ اس فائل کی طرف اشارہ کرنے والا پروگرام کوئریاں سیدھی فہرست شدہ سروروں کو بھیجتا ہے اور stub کو چھوڑ دیتا ہے، اس لیے ہر لنک کی پالیسی اب اس پر لاگو نہیں ہوتی۔ چنانچہ ایک ہی مشین پر دو پروگرام ایک ہی نام کا مختلف جواب دے سکتے ہیں، اور کوئی بھی خراب نہیں۔

NSS کے ذریعے ایک تلاش کا پیچھا کریں

glibc نام کا جواب کون دے گا یہ طے کرنے کے لیے /etc/nsswitch.conf پڑھتا ہے۔ جس hosts لائن میں resolve ہے وہ سوال nss-resolve کو بھیجتی ہے، جو D-Bus کے ذریعے resolved سے پوچھتا ہے اور ہر لنک کا جواب پاتا ہے۔ صرف files dns والی لائن کوئری اس پتے پر بھیجتی ہے جو /etc/resolv.conf کے پاس ہے۔

یہی ایک لائن براؤزر اور dig کے درمیان زیادہ تر اختلاف کی وضاحت کرتی ہے۔ dig سیدھا resolv.conf پڑھتا ہے اور NSS کو کبھی نہیں چھوتا، اس لیے یہ ایپلیکیشن کے استعمال کردہ راستے کے بجائے stub یا اوپر کے سرور کی جانچ کرتا ہے۔ getent hosts internal.example NSS سے گزرتا ہے، اور اس کے جواب کا dig کے جواب سے موازنہ پہلی کارآمد پیمائش ہے۔

جو ایپلیکیشن اپنا حل کنندہ ساتھ لاتی ہیں، یا کسی مقررہ اینڈ پوائنٹ پر HTTPS کے ذریعے DNS بولتی ہیں، وہ دونوں راستے چھوڑ دیتی ہیں۔ resolv.conf میں یا resolved کی حالت میں کچھ بھی انہیں محدود نہیں کرتا۔

دیکھیں فائل کس کی ہے اور کدھر اشارہ کرتی ہے

کچھ بھی بدلنے سے پہلے لنک زنجیر پڑھیں، کیونکہ ملکیت طے کرتی ہے کون سی فائل مستند ہے۔ نیچے ہر حکم صرف حالت پڑھتا ہے۔

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

پہلی لائن لنک اور اس کا ہدف ساتھ چھاپتی ہے، اور VPN اسکرپٹ کی ملکیت والی عام فائل کا مطلب ہے کہ حل کنندہ اس تحریر کو کبھی ان پٹ نہیں سمجھتا۔ حالت کی آؤٹ پٹ ہر لنک کے سرور اور وہ روٹنگ ڈومین فہرست کرتی ہے جو طے کرتے ہیں ہر کوئری کدھر جائے گی۔ nsswitch لائن بتاتی ہے stub سے بالکل رجوع ہوتا ہے یا نہیں، اس لیے فائل میں stub پتہ ہو مگر وہاں resolve نہ ہو تو کوئریاں مقامی سننے والے تک پہنچتی ہیں جبکہ تقسیم کوئی نہیں سنبھالتا۔ وہ آخری فہرست بھی اہم ہے، کیونکہ stub-resolv.conf کے بغیر میزبان یہاں بیان کردہ ترتیب نہیں چلاتا۔

اگر زنجیر کسی اور پیکیج کی زیر انتظام فائل پر ختم ہو، تو VPN کلائنٹ اور وہ پیکیج ملانے والے دو مالک ہیں۔ لنک بدلنے سے ایک مالک کا کام ضائع ہوتا ہے اور دوسرے کا اپنی جگہ رہتا ہے۔

لنک کے مالک کے پاس مرمت کریں

VPN کنکشن کو اپنے سرور اور ڈومین اپنے لنک پر درج کرنے چاہئیں، پھر منقطع ہونے پر واپس لے لینے چاہئیں۔ NetworkManager کا resolved انضمام اور کلائنٹ کا اپنا معاون دونوں ایسے ہی کام کرتے ہیں؛ صرف resolv.conf دوبارہ لکھنے والی اسکرپٹ ایسا نہیں کرتی۔

پہلے سے موجود لنک پر رن ٹائم ترتیبات طریقہ کار دکھاتی ہیں۔ resolvectl dns tun0 10.40.0.53 ایک سرور جوڑتا ہے، اور resolvectl domain tun0 '~corp.example' ایک روٹنگ ڈومین جوڑتا ہے۔ ٹلڈا (~) وزن اٹھانے والا حرف ہے: یہ اس لاحقے کی کوئریاں اسی لنک تک محدود کرتا ہے اور باقی سب کو سکون میں چھوڑ دیتا ہے، جبکہ اس کے بغیر وہی قدر تلاش ڈومین بن جاتی ہے اور تقسیم بھاپ بن جاتی ہے۔ وہ پتے تجربہ گاہ کی مثالیں ہیں، مستقل ترتیب نہیں۔ resolvectl query host.corp.example سے تصدیق کریں اور پڑھیں کون سا لنک جواب دے۔

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

کام کرتی حالت کیسی دکھتی ہے

صحتمند نتیجہ تینوں عکسوں میں ہم آہنگ ہوتا ہے: ہر لنک کے سرور VPN کے دیے ہوئے سے میل کھاتے ہیں، روٹنگ ڈومین صرف اندرونی لاحقے ڈھانپتے ہیں، اور اہم ایپلیکیشن اندرونی نام حل کرتی ہے جبکہ عوامی نام اب بھی مقامی راستہ لیتا ہے۔ ایک کامیاب کوئری اس اتفاق سے کم ثابت کرتی ہے۔

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