لینکس کی دو سروسز کو روکیں جو /etc/resolv.conf پر مقابلہ کر رہی ہیں

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

جائزہ 1: کیا یہ سمبولک لنک ہے، اور کہاں

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

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved کے stub راستے کی طرف لنک کا مطلب ہے کہ فائل کا مواد پیدا ہوتا ہے، اور دستی ترمیم اگلے واقعے میں اوپر لکھ دی جائے گی۔ nameserver لائنوں والی عام فائل عام طور پر وہی کلائنٹ یا DHCP ہک لکھتا ہے جو جڑنے پر چلتا ہے۔ دونوں جائز ہیں؛ اہم بات یہ ہے کہ کچھ بھی بدلنے سے پہلے جانیں کہ آپ کے پاس کون سی ہے۔

جائزہ 2: کون سا ڈیمون چل رہا ہے

جانیں کہ اصل میں کیا فعال ہے، نہ کہ کیا نصب ہے۔ جدید تقسیم میں کئی حل کرنے والے ہو سکتے ہیں، اور loopback انٹرفیس پر پورٹ 53 رکھنے والا ہی جواب دیتا ہے:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

اسٹیٹس آؤٹ پٹ ہر لنک کے DNS سرورز اور روٹنگ ڈومینز بتاتا ہے، جو split DNS کے لیے درکار نقشہ ہے۔ اگر اندرونی نام اندرونی سرور پر اور باقی سب عوامی سرور پر جانے چاہئیں، تو وہ پالیسی ہر لنک کے ڈومینز میں رہتی ہے، اور اسے فائل میں مستقل nameserver فہرست میں ہموار کرنا اس فرق کو خاموشی سے کھو دیتا ہے۔

NetworkManager کی اپنی کنفیگریشن طے کرتی ہے کہ ان میں سے کون سا بیک اینڈ استعمال ہو۔ مرکزی کنفیگریشن فائل میں اس کی dns= سیٹنگ اس کے اندرونی حل کرنے والے، dnsmasq، systemd-resolved اور none کے درمیان چنتی ہے، اور تقسیم نے آپ کی طرف سے چن لیا ہو سکتا ہے۔ اس میزبان پر “DNS درست کرنے” کا مطلب طے کرنے سے پہلے وہ سیٹنگ پڑھیں۔

جائزہ 3: VPN کلائنٹ کو کیا لکھنے کی اجازت ہے

تنازعہ عام طور پر یہیں رہتا ہے۔ جو VPN کلائنٹ حل کرنے والے کی فائل براہِ راست دوبارہ لکھتا ہے وہ اس ہر سروس سے لڑے گا جو اسے بھی سنبھالتی ہے، اور ہارنے والا وہ ہے جو پہلے چلتا ہے۔ حالیہ OpenVPN ریلیزز فائل دوبارہ لکھنے کے بجائے DNS سیٹنگز systemd-resolved کو دے سکتی ہیں، جو آپ کی مطلوبہ تعاون والی روش ہے؛ پرانی اسکرپٹس اور ہاتھ سے لکھے ہک اکثر پرانا معاون آلہ بلاتے ہیں یا فائل پر سیدھا لکھ دیتے ہیں۔

WireGuard کی صورتِ حال شکل میں مشابہ ہے: انٹرفیس کنفیگریشن خود DNS کا انتظام نہیں کرتی، اردگرد کے اوزار کرتے ہیں، حل کرنے والے کے معاون یا resolved انضمام کے ذریعے۔ اگر ایسے دو معاون نصب ہوں تو دونوں جڑنے کے وقت اپنا نظریۂ دنیا نافذ کرنے کی کوشش کریں گے۔

اندازہ لگانے کے بجائے کلائنٹ کے up اور down ہک پڑھیں۔ /etc/openvpn/up.sh یا مساوی ڈائریکٹری میں چند سطریں shell اس رویے کی وضاحت کرتی ہیں جو ورنہ بےترتیب لگتا ہے، اور کلائنٹ کو مقابلے کے بجائے تعاون پر مجبور کرنے کی جگہ بھی وہی ہے۔

جائزہ 4: اسے مالک کے ہاں درست کریں، فائل میں نہیں

مالک معلوم ہونے کے بعد، DNS کو اسی مالک کے معاون انٹرفیس کے ذریعے ترتیب دیں۔ systemd-resolved کے لیے اس کا مطلب مستقل فائل کے بجائے ہر لنک کی سیٹنگز اور روٹنگ ڈومینز ہیں؛ NetworkManager کے لیے کنکشن پروفائل کی DNS سیٹنگز اور منتخب بیک اینڈ؛ resolvconf انضمام استعمال کرنے والی تقسیم کے لیے اس معاون کے ذریعے لکھنا۔

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

جہاں دو اجزاء کو واقعی ساتھ رہنا ہو، انہیں الگ کام دیں۔ نیٹ ورک مینیجر کو انٹرفیس سطح کی کنفیگریشن کی ملکیت دیں، VPN کلائنٹ کو اسی انضمام کے ذریعے ہر لنک کے DNS اور ڈومینز شامل کرنے دیں، اور فائل براہِ راست لکھنے والی تیسری اسکرپٹ ہٹا دیں۔ systemd-resolved کی دستاویز ان موڈز کی وضاحت کرتی ہے جنہیں یہ سپورٹ کرتا ہے اور ہر ایک /etc/resolv.conf میں کیا ظاہر کرتا ہے۔ وہ موڈ چنیں جو آپ کو کتنی پالیسی رکھنی ہے اس سے میل کھاتا ہو۔ اگر split DNS اہم ہے تو ہر لنک کے ڈومینز والا stub بندوبست اسے محفوظ رکھتا ہے، جبکہ upstream سرورز کو فائل میں نقل کرنے والا موڈ اسے خاموشی سے ہموار کر دیتا ہے۔

دوبارہ جڑنے کے بعد تصدیق کریں، ترمیم کے بعد نہیں

آپ کی تبدیلی کے فوراً بعد درست نظر آنے والی فائل کچھ ثابت نہیں کرتی، کیونکہ اگلا واقعہ ابھی پیش نہیں آیا۔ وہ ترتیب چلائیں جو پہلے اسے توڑتی تھی: ٹنل کو نیچے اتاریں اور دوبارہ اوپر کریں، DHCP لیز کی تجدید کریں یا انٹرفیس بدلیں، پھر وہی اقدار دوبارہ پڑھیں۔

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

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