آپ کا /etc/hosts اندراج VPN کے DNS تک کیوں نہیں پہنچتا

آپ نے /etc/hosts میں ایک نام شامل کیا، VPN سے جڑے اور توقع کی کہ ریکارڈ سب کو نظر آئے گا۔ ایسا نہیں ہوتا، اور حیرت عام طور پر دوسری علامت کے ساتھ آتی ہے: نام آپ کی مشین پر حل ہوتا ہے اور ساتھی کی مشین پر ناکام ہوتا ہے، جو خراب VPN DNS سروس جیسا لگتا ہے اور دراصل hosts فائل وہی کر رہی ہے جس کے لیے بنائی گئی تھی۔ hosts فائل مقامی نام حل کرنے کی ترتیب ہے، زون کی تازہ کاری نہیں، اور عام VPN کنکشن میں کوئی چیز اسے اپ لوڈ نہیں کرتی۔

Hosts مقامی تبدیلی ہے، زون کی تازہ کاری نہیں

فائل ان نقشوں کی فہرست ہے جنہیں نام سروس لائبریریاں DNS سرور سے پوچھنے سے پہلے یا اس کے بجائے دیکھتی ہیں۔ 10.40.0.20 build.corp.example جیسی سطر صرف اسی ایک مشین پر ایپلیکیشنز کے نتائج بدلتی ہے۔ یہ ریکارڈ نہیں بناتی، سرنگ سے نہیں گزرتی، اور جس DNS سرور کی طرف سرنگ اشارہ کرتی ہے اسے اس کے وجود کا کوئی علم نہیں۔

اسی لیے ناکامی غیر متوازن ہے۔ آپ کا کلائنٹ فائل سے جواب پاتا ہے۔ دوسرا کلائنٹ VPN کے DNS سرور سے پوچھتا ہے، جو کچھ واپس نہیں کرتا، اور ایپلیکیشن بتاتی ہے کہ نام موجود نہیں۔ دونوں مشینیں درست برتاؤ کر رہی ہیں؛ صرف ایک کے پاس ایسی تبدیلی ہے جو دوسرے نے کبھی نہیں دیکھی۔

دو حکم، دو مختلف اجزاء

اس بحث کو روکنے کا تیز ترین طریقہ یہ ہے کہ فرق کو دو حکموں میں نظر آنے والا بنائیں، دونوں hosts اندراج والے کلائنٹ پر چلائے جاتے ہیں:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

پہلا سسٹم کے اپنے تلاش کے راستے سے پوچھتا ہے، جو عام glibc سسٹم میں DNS سے پہلے مقامی فائلیں پڑھتا ہے۔ دوسرا اس پتے کے سرور کو براہ راست DNS استفسار بھیجتا ہے اور مقامی فائلوں کو بالکل نہیں دیکھتا۔ جب پہلا آپ کا اندراج واپس کرے اور دوسرا NXDOMAIN، تو آپ نے ثابت کر دیا کہ ریکارڈ DNS میں موجود نہیں اور آپ کی مشین مقامی تبدیلی سے جواب دے رہی ہے۔

ترتیب ترتیب دی جا سکتی ہے، اور کسی خاص ڈسٹری بیوشن کے بارے میں کوئی نتیجہ نکالنے سے پہلے اسے جانچنا مناسب ہے۔ /etc/nsswitch.conf میں hosts: سطر دیکھیں؛ hosts: files dns پہلے فائلیں دیکھتا ہے۔ صرف ترتیب بدلنے کے لیے اس مثال کو کام کرتی ترتیب پر نقل نہ کریں، کیونکہ حقیقی سسٹم اکثر ایسے اضافی ذرائع اور مشروط سروس اندراجات کی فہرست دیتے ہیں جو مثال میں نہیں ہیں۔

systemd-resolved جانچ کو دھندلا کرتا ہے

systemd-resolved استعمال کرنے والے سسٹم میں مقامی stub hosts ڈیٹا بیس سے بھی نام فراہم کرتا ہے۔ اس لیے 127.0.0.53 سے استفسار کرنا دور دراز سرور کی آزاد جانچ نہیں، اگرچہ یہ DNS استفسار جیسا لگتا ہے اور ویسا ہی برتاؤ کرتا ہے۔ آپ تصدیق کر سکتے ہیں کہ حل کنندہ کیا جانتا ہے اور کن سرورز سے پوچھے گا بذریعہ:

resolvectl query build.corp.example
resolvectl status

status کا آؤٹ پٹ ہر لنک کے لیے DNS سرور بتاتا ہے، اور اسی طرح آپ جان لیتے ہیں کہ VPN لنک کو حل کنندہ ملا بھی یا نہیں۔ وہ سوال hosts اندراج سے الگ ہے اور جب نجی نام ایک شخص کے بجائے ہر صارف کے لیے ناکام ہو تو پوچھنے کے قابل سوال وہی ہے۔

ایپلیکیشنز ایک اور پرت شامل کر سکتی ہیں۔ اپنی DNS-over-HTTPS ترتیب والا براؤزر، اپنی حل کنندہ ترتیب والا کنٹینر، یا پروسیس کی پوری زندگی تلاش کو کیش کرنے والا رن ٹائم ہر ایک سسٹم سے مختلف جواب دے سکتا ہے۔ یہ ماننے کے بجائے کہ ایک حکم مشین کے ہر پروگرام کی وضاحت کرتا ہے، اس ایپلیکیشن کی جانچ کریں جو آپ کے لیے اہم ہے۔

VPN میں نام دراصل کیا بانٹتا ہے

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

hosts فائلیں تقسیم کرنا ایک جائز متبادل ہے، اور یہ نام سروس نہیں بلکہ اینڈ پوائنٹ انتظام ہے۔ اگر آپ اسے چنیں، تو فائل کو بیڑے کا انتظام کرنے والا تعینات، ورژن اور ہٹائے، اور ڈیزائن میں اسی طرح بیان کیا جانا چاہیے۔ «VPN اسے سنبھالتا ہے» اس عمل کی وضاحت نہیں ہے۔

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

حل شدہ نام راستہ نہیں ہے

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

لہٰذا جب رپورٹ ہو کہ «نام حل ہوتا ہے لیکن سروس قابل رسائی نہیں»، تو سسٹم کی تلاش کا VPN کے DNS سرور سے واضح استفسار سے موازنہ کریں، پھر جو پتہ ملا اسے اس پتے سے جانچیں جو سروس دراصل استعمال کرتی ہے۔ systemd-resolved حوالہ ان مقامی ذرائع کی دستاویز کرتا ہے جنہیں یہ دیکھتا ہے، اور اس موازنے کے لیے ضروری نقشہ یہی ہے۔

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