resolv.conf میں ترمیم VPN منقطع ہونے کے بعد DNS درست نہیں کرتی

آپ VPN منقطع کرتے ہیں، ping 1.1.1.1 اب بھی جواب دیتا ہے، اور صفحہ بالآخر ہار ماننے سے پہلے ہر نام کی تلاش لٹکی رہتی ہے۔ پھر cat /etc/resolv.conf ایسا نام سرور دکھاتا ہے جو کبھی صرف ٹنل کے اندر موجود تھا، عموماً فہرست میں پہلا۔ اس سطر کو حذف کرنا تقریباً دس منٹ کے لیے درست کرتا دکھتا ہے، یہاں تک کہ کوئی سسپنڈ، Wi-Fi رومنگ یا ری اسٹارٹ اسے واپس لے آئے۔ آپ نے جو فائل میں ترمیم کی وہ ترتیب نہیں ہے؛ وہ لنک کی حالت کی عکاسی ہے جس کا مالک کوئی دوسرا جزو ہے.

ایک پرانا اندراج ہر تلاش پر سیکنڈ کیوں خرچ کرتا ہے

glibc حل کنندہ نام سروروں کی فہرست ترتیب سے چلتا ہے اور اگلا آزمانے سے پہلے وقت کی حد ختم ہونے کا انتظار کرتا ہے، اور resolv.conf(5) اس فہرست کو تین اندراجات تک محدود کرتا ہے۔ ٹنل جانے کے بعد 10.8.0.1 جیسا ٹنل کی طرف کا حل کنندہ فہرست کے اوپر رکھیں، پھر ہر تلاش جواب دینے والے سرور تک پہنچنے سے پہلے وقت کی حد ادا کرتی ہے۔ علامت کے DNS خرابی کے بجائے مردہ کنکشن لگنے کی یہی وجہ ہے: براؤزر بلاک ہوتے ہیں، وقت ختم ہوتا ہے اور کبھی کبھی ایسا کیش شدہ پتہ پیش کرتے ہیں جو بعد میں پرانا ہو جاتا ہے۔

یہ بھی بتاتا ہے کہ شکایت «انٹرنیٹ خراب ہو گیا» کی صورت میں کیوں آتی ہے۔ کسی IP پتے پر ping ثابت کرتا ہے کہ لنک ٹھیک ہے، جس سے خرابی ایپلیکیشن کی لگتی ہے۔ حل کنندگان کی فہرست پہلی چیز ہے جو پڑھنی چاہیے اور آخری جس میں ترمیم کرنی چاہیے۔

افسانہ: resolv.conf ایک سیٹنگز فائل ہے

بدلنے سے پہلے پوچھیں کہ یہ راستہ دراصل کیا ہے:

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

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

resolvectl status وہ منظر ہے جو سچ بتاتا ہے: فی لنک DNS سرور، روٹنگ ڈومین، اور کیا ٹنل لنک اب بھی موجود ہے۔ resolvectl query example.com مزید آگے جا کر دکھاتا ہے کہ کس انٹرفیس نے جواب دیا۔ فائل کو چھونے سے پہلے دونوں استعمال کریں، اور یاد رکھیں کہ اپنا محفوظ DNS رکھنے والا براؤزر یہ سب نظرانداز کرتا ہے۔

کچھ بھی تبدیل کرنے سے پہلے مالک تلاش کریں

عام طور پر تین اجزا ایک ہی ترتیب کے لیے مقابلہ کرتے ہیں: systemd-resolved، NetworkManager اور جو VPN کلائنٹ نے نصب کیا۔ پہلے زندہ کی شناخت کریں:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

اگر resolved فعال ہے اور سمبولک لنک اس کے stub کی طرف اشارہ کرتا ہے، تو عالمی فائل تیار شدہ آؤٹ پٹ ہے اور آپ کی ترمیم ظاہری ہے۔ اگر NetworkManager کنکشن کا مالک ہے، تو سرور کنکشن پروفائل کے ہیں، اس لیے درستی فائل میں ترمیم نہیں بلکہ nmcli خاصیت کی تبدیلی ہے۔ اگر وینڈر کا ڈیمون چل رہا ہے، تو اگلی جڑت تک صرف اس کا اپنا بحالی راستہ بچتا ہے۔

کلائنٹ کی چھوڑی ہوئی لنک حالت صاف کریں

مارا گیا کلائنٹ اپنا صفائی کا ہک نہیں چلا سکتا۔ SIGKILL بالکل پکڑا نہیں جا سکتا، جبکہ SIGINT اور SIGTERM پکڑے جا سکتے ہیں، اس لیے زبردستی مارنے کے بعد «بس رک گیا» ٹنل اکثر انٹرفیس کی رجسٹریشن اور حل کنندہ کا اندراج دونوں جگہ پر چھوڑ دیتا ہے۔ مخصوص PID تلاش کریں اور سگنل صرف اسی کو بھیجیں:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

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

resolvectl revert اس لنک کی رن ٹائم DNS ترتیب ری سیٹ کرتا ہے، جو حل کنندہ دوبارہ شروع کرنے سے تنگ تر اور عالمی فائل میں ترمیم سے بہت تنگ تر ہے۔ اگر ٹنل لنک مکمل طور پر چلا گیا ہے، تو systemctl restart NetworkManager کنکشن کی حالت دوبارہ بناتا ہے اور یہی وہ قدم ہے جس پر ماخذ تھریڈ بار بار واپس آتے ہیں۔ Restart=always والے سروس مینیجر سے ہوشیار رہیں، کیونکہ وہ مارے گئے کلائنٹ اور اس کی DNS ترتیبات کو سیدھا واپس رکھ سکتا ہے۔

دوسری سمت: دھکیلا گیا مگر کبھی نہ پہنچا DNS

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

حوالگی ہاتھ سے کر کے جانچیں، یہ «سرور غلط ہے» اور «کسی نے لاگو نہیں کیا» کو الگ کرتا ہے:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

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

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

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

ایسے حل جو اگلی خلل بن جاتے ہیں

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

systemd-resolved بند کرنا اور عوامی سرور سخت کوڈ کرنا دوسرا مقبول قدم ہے۔ یہ جڑنے اور منقطع ہونے کو قابل قیاس بناتا ہے اور ہر دوسرے نیٹ ورک کے لیے فی لنک DNS ہٹا دیتا ہے، جو اندرونی ناموں کے لیے منقسم DNS توڑتا ہے اور ایسے ٹنل کا مقصد باطل کرتا ہے جو سوالات کو اندر رکھنے کے لیے بنایا گیا ہو۔ resolvconf نصب کرنا اور عوامی سرور پن کرنا اضافی تہہ کے ساتھ وہی لاگت ہے۔ ان میں سے کسی کو تشخیص سمجھیں: اگر یہ براؤزنگ واپس لاتا ہے، تو آپ نے سیکھا کہ حل کنندہ کا انضمام قصوروار ہے، نہ کہ عوامی سرور درست ہیں۔

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