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 रिकॉर्ड और बाहरी निर्देशिका—इनमें से प्रत्येक को अपना पुनर्प्राप्ति चरण चाहिए हो सकता है। सफल फ़ाइल प्रतिलिपि इस बात का प्रमाण नहीं है कि सेवा लौटती है; केवल वही प्रमाण मायने रखता है जो पुनर्निर्मित एंडपॉइंट मूल के समान स्वीकृति परीक्षण पास करता है।