resolvconf ڈیٹابیس سے پرانا VPN ریکارڈ ہٹانا

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

تصدیق کریں کہ resolvconf حالت کا مالک ہے

پہلے مالک کی شناخت کریں، کیونکہ systemd-resolved کے تحت وہی علامت مختلف کمانڈز اور مختلف مرمت مانگتی ہے۔ resolvconf پیکیج /run/resolvconf کے تحت ڈیٹابیس رکھتا ہے اور /etc/resolv.conf کو اس فائل کی طرف اشارہ کرتا ہے جو وہ اسی ڈیٹابیس سے بناتا ہے۔ دو مطالعے سوال طے کرتے ہیں: سمبولک لنک کا ہدف، اور یہ کہ پیکیج نصب اور فعال ہے یا نہیں۔ /run/systemd/resolve کے تحت ہدف کا مطلب دوسرا ڈیزائن ہے، جہاں نیچے کا کچھ بھی لاگو نہیں ہوتا۔

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

اگر لنک کہیں اور اشارہ کرتا ہے یا پیکیج موجود نہیں، تو یہیں رکیں۔ نام ادھار لینے والا اور کسی دوسرے حل کنندہ منتظم کی طرف سے فراہم کردہ مطابقت پذیر غلاف اس ڈیٹابیس کا مالک نہیں ہے۔

ڈیٹابیس میں اندراجات ہوتے ہیں، جواب نہیں

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

sudo resolvconf --list
sudo resolvconf -i

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

کلید کو دوبارہ بنانے کے بجائے آؤٹ پٹ سے نقل کریں۔ اندراج کو صرف اس لیے tun0 نہیں کہا جاتا کہ کسی پرانی اسکرپٹ نے وہ نام استعمال کیا تھا۔

ثابت کریں کہ ریکارڈ کا کوئی مالک نہیں

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

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

مالک منتظم کے ذریعے معمول کا منقطع ہونا پہلا علاج ہے۔ یہ وہ واپس لیتا ہے جو اس کنکشن نے نصب کیا تھا اور دیگر فراہم کنندگان کو اچھوتا چھوڑ دیتا ہے۔

ہٹانا اور دوبارہ تحریر جانچیں

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

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

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

resolvconf -u صرف وہی اپ ڈیٹ اسکرپٹس چلاتا ہے۔ یہ کبھی پرانے ریکارڈ کی شناخت یا اسے مٹاتا نہیں، اور پرانے اندراجات سے دوبارہ بنانے پر وہی ناپسندیدہ فائل پھر پیدا ہوتی ہے۔

مارا گیا منقطع ہونے والا ہک ریکارڈ پیچھے چھوڑ دیتا ہے

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

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

پھر زندگی کا چکر آزمائیں: جڑیں، منقطع کریں، ریکارڈ دوبارہ فہرست کریں۔ اندراج کا خود بخود غائب ہونا ہی اس بات کا واحد ثبوت ہے کہ مرمت قائم ہے۔