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

جو اب بھی آپ کے پاس ہے اس کا جائزہ لیں

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

PathDepends onUsually fails when
Provider consoleAccount access and the provider's own APICredentials live in a wiki only reachable over the tunnel
Management subnetA second interface and its own routingThe bad change was a global route or firewall policy
Second tunnelA different listener, port and credentialsBoth listeners were changed in the same edit
Physical or local consoleBeing in the buildingNobody has been in the building for a year

تیسرے کالم کو تجرید نہیں، ناکامیوں کی فہرست سمجھ کر پڑھیں۔ ان راستوں میں سے دو عام طور پر ایک ہی وجہ سے ناکام ہوتے ہیں۔ جدول ہی وہ طریقہ ہے جس سے آپ خرابی کے آپ کو سمجھانے سے پہلے اسے محسوس کرتے ہیں۔

خودمختاری انحصار کا سوال ہے

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

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

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

ایک کنٹرول شدہ تبدیلی کے لیے دوسرا راستہ استعمال کریں

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

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

یادداشت سے نہیں، بحالی کے راستے سے تصدیق کریں

اہم جانچ یہ ہے کہ کیا عام راستہ واپس آتا ہے، اور بحالی کا سیشن ہی وہ جگہ ہے جہاں آپ اس کی ترتیب سے تصدیق کرتے ہیں:

systemctl status openvpn-server@server --no-pager
ss -lntup | grep -E ':(1194|443)\b'
nft list ruleset | sed -n '1,40p'
journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30

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

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

اثاثوں کی فہرست کو تازہ رکھیں

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

درج کریں کہ کون ہر راستہ استعمال کر سکتا ہے، وہ کیا اجازت دیتا ہے اور اسناد کیسے گھمائی جاتی ہیں۔ بغیر مالک کے بحالی کا راستہ بھولا ہوا داخلی دروازہ بن جاتا ہے، جو باہر بند ہونے سے مختلف قسم کی ناکامی ہے۔

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