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 रेकर्ड र बाह्य डिरेक्टरीले प्रत्येकले आफ्नै पुनःप्राप्ति चरण चाहिन सक्छ। सफल फाइल प्रतिलिपि सेवा फर्किन्छ भन्ने प्रमाण होइन; गणना हुने एकमात्र प्रमाण मूलजस्तै त्यही स्वीकृति परीक्षा उत्तीर्ण गर्ने पुनर्निर्मित अन्त्यबिन्दु हो।