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 রেকর্ড ও বাইরের ডিরেক্টরি—প্রত্যেকেরই নিজস্ব পুনরুদ্ধার পদক্ষেপ লাগতে পারে। সফল ফাইল কপি সেবাটি ফিরে আসার প্রমাণ নয়; একমাত্র গ্রহণযোগ্য প্রমাণ হলো পুনঃনির্মিত একটি এন্ডপয়েন্ট যা মূলের মতোই একই গ্রহণযোগ্যতা পরীক্ষায় উত্তীর্ণ হয়।