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

ایسا چیک پوائنٹ بنائیں جو آپ واقعی بحال کر سکیں

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

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

منسوخیوں کو ترتیب سے الگ رکھیں

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

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

سرنگ ناکام ہونے پر میزبان تک پہنچیں

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

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

ایک ہی نظر ثانی لاگو کریں اور جانیں کہ وہ کب مؤثر ہوتی ہے

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

انتخاب سے پہلے یونٹ کی تعریف دیکھیں: systemctl show -p ExecReload openvpn@server آپ کو بتاتا ہے کہ reload ہک ہے یا نہیں۔ پھر نظر ثانی لاگو کریں اور کچھ اور بدلنے سے پہلے جرنل میں پہلی نئی غلطیاں پڑھیں۔

تصدیق کریں، درج کریں اور بعد میں تحقیق کریں

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

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

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

متعلقہ مضامین