VPN سرور بیک اپ: طے کریں کہ کیا بحال ہونے کے قابل ہونا چاہیے

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

دوبارہ تعمیر کے ہدف سے شروع کریں

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

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

شناخت وہ حصہ ہے جو آپ دوبارہ نہیں بنا سکتے

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

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

ایک لمحے میں حالت محفوظ کریں

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

wg showconf wg0 > /srv/backup/wg0.runtime.conf
sqlite3 /var/lib/vpn/admin.db ".backup '/srv/backup/admin.db'"
cp -a /etc/wireguard /srv/backup/etc-wireguard
sha256sum /srv/backup/*.conf > /srv/backup/MANIFEST

پہلا حکم چلتی ہوئی انٹرفیس کو ترتیب کے طور پر واپس چھاپتا ہے، جو انتظامی اوزار کے بجائے ہاتھ سے شامل کیے گئے ہم منصبوں کو پکڑنے کا تیز ترین طریقہ ہے؛ اسے wg(8) دستاویز درج کرتی ہے۔ sqlite کی سطر انتظامی ڈیٹا بیس کے لیے نمونہ ہے: بیک اپ کا حکم ایسی مستقل نقل بناتا ہے جبکہ لکھنے والا جاری رہتا ہے۔ ڈائریکٹری کی نقل اجازتیں محفوظ رکھتی ہے، جو اہم ہے کیونکہ وہ چابی کی فائلیں صرف root پڑھ سکتا ہے۔ مینی فیسٹ ہی آپ کو مکمل آرکائیو کو کٹے ہوئے سے الگ پہچاننے دیتا ہے۔

بحالی کو ممکن بنائیں اور پھر آزما کر دیکھیں

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

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