SIGKILL کے بعد OpenVPN DNS باقی رہتا ہے: پہلے مالک کی جانچ کریں

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

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

طے کریں کہ کس قسم کا اخراج ہوا

Community ایڈیشن میں OpenVPN کے لیے SIGINT اور SIGTERM دونوں پرسکون اخراج کی درخواستیں ہیں۔ SIGKILL پکڑا نہیں جا سکتا: اسے نہ روکا جا سکتا ہے نہ سنبھالا، اس لیے کوئی شٹ ڈاؤن روٹین چلنے کا موقع نہیں پاتی۔ سامنے والے ٹرمینل میں عام Ctrl+C SIGINT پیدا کرتا ہے، جبکہ انتظار چھوڑ دینے والا نگران عام طور پر SIGKILL تک بڑھتا ہے۔ فرق اہم ہے کیونکہ صرف دوسری صورت ہی ہکوں کے چھوڑے جانے کی ضمانت دیتی ہے۔

screen یا tmux کے اندر چلانا اس بات کو نہیں بدلتا کہ Ctrl+C کون سا سگنل بھیجتا ہے۔ جانچیں کہ عمل نے واقعی کیا حاصل کیا، نہ کہ ٹرمینل عام طور پر کیا کرتا ہے۔

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

طے کریں کہ ریزولور کس کا ہے

systemd-resolved، resolvconf طرز کی اسکرپٹ اور سادہ فائل دوبارہ لکھنا تین مختلف مالک ہیں۔ پہلا فی لنک ترتیبات یادداشت میں رکھتا ہے اور انٹرفیس غائب ہونے پر انہیں گرا دیتا ہے۔ دوسرا ایسے ریکارڈ رکھتا ہے جو کوئی چیز ہٹانے تک رہتے ہیں۔ تیسرا فائل لکھتا ہے اور بحالی اسی پر چھوڑ دیتا ہے جس نے لکھی۔

مرمت کا حکم چننے سے پہلے مالک کی شناخت کریں۔ اسی علامت کے تین مختلف درست جواب ہیں، انحصار اس پر ہے کہ کون سا زیرِ استعمال ہے۔

NetworkManager کے زیرِ انتظام VPN پہلے سے ریزولور تبدیلیوں کا مالک ہو سکتا ہے۔ اس کے اوپر دوسرا معاون شامل کرنے سے ایک ہی لنک پر مقابلہ کرنے والے دو مالک بنتے ہیں، اور ہارنے والے کی حالت اگلی دوبارہ کنکشن پر پھر ظاہر ہوتی ہے۔ اگر مینیجر ذمہ دار ہو تو ترتیب اسکرپٹ میں نہیں، مینیجر میں درست کریں۔

down ہک کیا کر سکتا ہے اور کیا نہیں

اسکرپٹ down TUN/TAP ڈیوائس بند ہونے کے بعد ایک بار چلتی ہے۔ شامل کرنے سے down-pre وہ ترتیب الٹ جاتی ہے اور اسکرپٹ اس وقت چلتی ہے جب ڈیوائس اب بھی موجود ہو، جس کی ضرورت زندہ لنک والے معاونوں کو ہوتی ہے۔

کوئی ہدایت ہک کو SIGKILL کے بعد نہیں چلاتی۔ مراعات بھی down-pre کے ذریعے بحال نہیں ہوتیں: اگر ڈیمن user یا group پر اترے یا chroot میں داخل ہو تو ہک اسی رسائی کے ساتھ چلتا ہے جو یہ چھوڑ جاتا ہے۔ بلایا گیا ہک پھر بھی ریزولور اپ ڈیٹ کرنے میں ناکام ہو سکتا ہے۔ OpenVPN حوالہ سگنلز اور کال بیک لائف سائیکل کا احاطہ کرتا ہے۔

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

وہ حالت جانچیں جو واقعی باقی ہے

systemd-resolved استعمال کرنے والے نظام پر، resolvectl status دکھاتا ہے کہ کون سا لنک اب بھی VPN کے DNS سرورز یا روٹنگ ڈومینز اٹھائے ہوئے ہے۔ وہ لنک کسی جا چکے کنکشن کا ہو سکتا ہے، یا کسی اور سرنگ کا جو اب بھی کھڑی ہے۔

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

دوسرا لنک چرائے بغیر بحال کریں

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

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