अनुपस्थित VPN सर्भर अपडेटका लागि परीक्षण गरिएको पुनःप्राप्ति मार्ग चाहिन्छ
अपडेटले सर्भरसम्म पुग्न तपाईंले प्रयोग गर्ने त्यही सेवा पुनः सुरु गर्न सक्छ। स्वचालन गर्नुअघि आउट-अफ-ब्यान्ड कन्सोललाई टनेलमा मात्र आधारित पुनःप्राप्ति योजनासँग तुलना गर्नुहोस्।
अनुपस्थित अपडेटहरू आफ्नै VPN मार्फत पुगिने सर्भरका लागि उचित नीति हुन्, र सँगै तिनीहरू तपाईंले आफैं सिर्जना गर्ने एउटै विफलता बिन्दु हुन्। प्याकेज क्रियाले सेवा पुनः सुरु गर्छ, टनेल खस्छ, र तपाईंले प्रयोग गरिरहनुभएको प्रशासनिक मार्ग त्यसैसँग हराउँछ। पुनःप्राप्तिका दुई मोडेल छन्, र तिनीहरूबीचको छनोट एउटा सर्तमा निर्भर छ: तपाईंसँग अपडेट हुँदै गरेको कुराबाट नजाने प्रवेश मार्ग छ कि।
दुई पुनःप्राप्ति मोडेल, एउटा निर्णायक सर्त
पहिलो मोडेल अपडेटमाथि भरोसा गर्छ र पछि तपाईं फेरि जोडिन सक्नुहुनेछ भनी मान्छ। VPN होस्टसम्म पुग्ने धेरै माध्यममध्ये एक हुँदा र टनेलको विफलताले त्यसको निदान गर्ने तपाईंको क्षमता हटाउँदैन भने यो काम गर्छ। दोस्रो मोडेलले पहिल्यै एउटा स्वतन्त्र मार्ग, सामान्यतया होस्टिङ प्रदायकको कन्सोल राख्छ, र टनेललाई मर्मतले सबैभन्दा बढी तोड्ने सम्भावना भएको कुराका रूपमा लिन्छ। दुवै मोडेल समर्थनयोग्य छन्, र तिनीहरूमध्ये एउटाले मात्र अग्रिम काम चाहिन्छ।
निर्णायक सर्त भन्न सजिलो छ र छोड्न पनि सजिलो छ। यदि मेसिनसम्मको हरेक प्रशासनिक मार्ग अपडेट हुँदै गरेको सेवाबाट जान्छ भने तपाईंसँग पुनःप्राप्ति मोडेल नै छैन, केवल एउटा अपेक्षा छ। परिवर्तन समीक्षामा यो ठूलो स्वरले भन्नुहोस्।
त्यो सर्त परीक्षण गर्न दस मिनेट लाग्छ र यो पहिलो अनुपस्थित अपडेटअघि हुनुपर्छ, घटनाको बेला होइन। सबै कुरा चलिरहेको बेला कन्सोल खोल्नुहोस्, प्रमाणहरू वैध छन् भनी पुष्टि गर्नुहोस्, र फेरि बन्द गर्नुहोस्। कन्सोल तपाईंले सोचेको होस्टमा खुल्छ भनी पुष्टि गर्नुहोस्। त्यसपछि राति 3 बजे तपाईंले साँच्चै प्रयोग गर्ने लगइन अझै काम गर्छ भनी पुष्टि गर्नुहोस्।
त्यो अन्तिम भाग सुन्दा लाग्नेभन्दा बढी महत्त्वपूर्ण छ। छ महिनाअघि पासवर्ड परिवर्तन भएको र कहिल्यै प्रमाणित नगरिएको कन्सोल खाता पुनःप्राप्ति मार्ग होइन; त्यो यस्तो मार्ग वर्णन गर्ने कागजात हो।
ब्याकअपले के पुनर्स्थापित गर्दैन
कन्फिगरेसन अभिलेख फाइलहरूको रेकर्ड हो, र अपडेटले फाइलभन्दा बढी कुरा बदल्छ। प्याकेज अवस्था, कर्नेल मोड्युल, सक्रिय युनिट लिङ्क र छुट्टै उपकरणबाट लागू गरिएका फायरवाल नियम सबै कन्फिगरेसन डाइरेक्टरीबाहिर बस्छन्, र तिनलाई बेवास्ता गर्ने पुनर्स्थापनाले कन्फिगर गरिएको देखिने तर अगाडि नपठाउने मेसिन बनाउँछ।
| What changed | Restored by a configuration backup | Needs its own action |
|---|---|---|
| Service unit or startup ordering | Partly, if the unit file was included | Package state and enabled links |
| Kernel module or interface support | No | Kernel or module rollback, or a boot-time decision |
| Peer or device authorization | Only if the backup predates the revocation | A deliberate decision about which peers return |
| Firewall rules applied outside the config | Only if they were captured | Replaying and verifying each rule |
अधिकारले आफ्नै लाइन पाउनुपर्छ। सम्झौता भएको उपकरण हटाउनुअघि लिइएको ब्याकअपले त्यो उपकरणको पहुँच खुसीसाथ पुनर्स्थापित गर्नेछ। अवरोधका बेला त्यसमा फर्किनु नै एउटा घटना दुई हुने बाटो हो, र पुनर्स्थापनाको निर्णय फाइलबारे जति स्पष्ट छ, त्यति नै स्पष्ट रूपमा सहकर्मीबारे पनि लिनुपर्छ।
रोलब्याकको विधि पनि महत्त्वपूर्ण छ। प्याकेजद्वारा व्यवस्थित फाइलमाथि पुरानो एक्जिक्युटेबल कपी गर्नु प्याकेज परिवर्तनको समर्थित उल्टाउने काम होइन, र यसले प्याकेज डाटाबेसलाई फाइलसिस्टमसँग नमिल्ने अवस्था वर्णन गर्न छोड्छ। प्याकेज म्यानेजरको आफ्नै डाउनग्रेड मार्ग वा प्रदायकले दिने स्न्यापसट प्रयोग गर्नुहोस्। प्याकेज डाटाबेसले अभिलेख गर्ने डाउनग्रेड मात्र तपाईंले दोहोर्याउन सक्नुहुन्छ।
यीमध्ये केही पनि ब्याकअपविरुद्ध छैन। यो प्रत्येक कलाकृतिले कुन तह ढाक्छ भनी जान्ने पक्षमा छ, किनकि आंशिक पुनर्स्थापनाको विफलता विधि मूल अवरोधभन्दा बढी अलमल्याउने हुन्छ। रनबुकमा प्रत्येक ब्याकअपको छेउमा तह लेख्नुहोस्।
चेकपोइन्ट, अपडेट, त्यसपछि बाहिरबाट प्रमाणीकरण
परिवर्तनअघिको अवस्था पछि तुलना गर्न सकिने रूपमा अभिलेख गर्नुहोस्: स्थापित संस्करण, सम्बन्धित सेवा युनिट, सुनिरहेका सकेट र हालको सहकर्मी सूची। लिनक्स होस्टमा चार आदेशले त्यसको अधिकांश भाग ढाक्छन्।
systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'पहिलोले कुन युनिट छन् र ती चलिरहेका छन् कि भनी देखाउँछ, दोस्रोले श्रोता साँच्चै बाँधिएको छ भनी पुष्टि गर्छ, र तेस्रोले विगत केही मिनेटको सेवाको आफ्नै विवरण दिन्छ। तीमध्ये कुनैले पनि ग्राहक जोडिन सक्छ भनी प्रमाणित गर्दैन, त्यसैले अर्को कदम होस्टबाहिर हुन्छ। ती पठनलाई तपाईंको तुलना आधारका रूपमा राख्नुहोस्।
टनेल प्रयोग नगर्ने सञ्जालबाट प्रमाणित गर्नुहोस्: एउटा अधिकृत ग्राहक प्रमाणित गर्नुहोस्, नाम समाधान गर्नुहोस्, र एउटा लक्षित अनुप्रयोगसम्म पुग्नुहोस्। इन्टरफेस माथि छ भन्ने स्थानीय स्थिति लाइन इन्टरफेसबारेको कथन हो, राउटिङ, कुञ्जी वा सहकर्मीलाई स्वीकार गर्ने नीतिबारे होइन।
त्यसपछि पुनः जोडिने मार्ग जानाजान परीक्षण गर्नुहोस्। सेवा एक पटक पुनः सुरु गर्नुहोस् र टनेल हस्तक्षेपबिना फर्केको पुष्टि गर्नुहोस्, किनकि बुटमा मात्र राम्ररी सुरु हुने सेवा तपाईंलाई सबैभन्दा नराम्रो क्षणमा चकित पार्नेछ।
त्यो असफल भए, परीक्षण गरिएको मार्ग प्रयोग गर्नुहोस्
पुनःप्राप्तिको क्रम भव्य छैन र यो काम गर्छ: स्वतन्त्र मार्गबाट होस्टसम्म पुग्नुहोस्, सेवाका आफ्नै लग पढ्नुहोस्, र विफलतासँग मिल्ने विशिष्ट चेकपोइन्ट पुनर्स्थापित गर्नुहोस्। हरेक प्रयासमा एउटा कुरा बदल्नुहोस् ताकि अर्को लग पठनले अर्थ राख्छ।
जडान फर्काउन धेरै नलेखिएका परिवर्तन गर्ने चाहनाको प्रतिरोध गर्नुहोस्। एकैचोटि पाँच सम्पादनले मर्मत गरिएको मेसिन पछि व्याख्या गर्न सकिँदैन, र अर्को अपडेटले साँच्चै भार बोकेको परिवर्तन फेरि भित्र्याउनेछ।
त्यसपछि प्रमाणसहित स्थायी नीति तय गर्नुहोस्। यदि अपडेटले कसैले अभिलेख नगरेको निर्भरता खोल्यो भने, उपचार भनेको कागजात र परीक्षण हो, अपडेट बन्द गर्नु होइन। यदि यसले सफासँग पुनः सुरु हुन नसक्ने सेवा खोल्यो भने, उपचार युनिटमा छ, तालिकामा होइन।
सर्तको नाम आउनेबित्तिकै तुलना सफासँग टुंगिन्छ। स्वतन्त्र मार्गले अनुपस्थित अपडेटलाई व्यवस्थापनयोग्य जोखिम बनाउँछ। त्यसको अभावले त्यही नीतिलाई अज्ञात पुनःप्राप्ति समय भएको नियोजित अवरोध बनाउँछ, र कुनै पनि स्वचालनले त्यो गणित बदल्दैन।