अनुपस्थित 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'पहला दिखाता है कि कौन-सी यूनिट हैं और वे चल रही हैं या नहीं, दूसरा पुष्टि करता है कि श्रोता वास्तव में बँधा है, और तीसरा आपको पिछले कुछ मिनटों का सेवा का अपना विवरण देता है। इनमें से कोई भी यह सिद्ध नहीं करता कि कोई क्लाइंट जुड़ सकता है, इसलिए अगला कदम होस्ट के बाहर से होता है। उन पठनों को अपना तुलना-आधार रखें।
ऐसे नेटवर्क से सत्यापित करें जो टनल का उपयोग नहीं करता: एक अधिकृत क्लाइंट का प्रमाणीकरण करें, एक नाम हल करें, और एक इच्छित अनुप्रयोग तक पहुँचें। इंटरफ़ेस के ऊपर होने की स्थानीय स्थिति पंक्ति इंटरफ़ेस के बारे में कथन है, रूटिंग, कुंजियों या साथी को स्वीकार करने वाली नीति के बारे में नहीं।
फिर पुनः-कनेक्शन मार्ग को जान-बूझकर परखें। सेवा को एक बार पुनः चालू करें और पुष्टि करें कि टनल बिना हाथ की दखल के लौट आती है, क्योंकि जो सेवा केवल बूट पर ठीक से शुरू होती है वह आपको सबसे बुरे पल में चौंकाएगी।
जब वह विफल हो, तो परखे हुए मार्ग का उपयोग करें
रिकवरी क्रम भव्य नहीं है और वह काम करता है: स्वतंत्र मार्ग से होस्ट तक पहुँचें, सेवा के अपने लॉग पढ़ें, और विफलता से मेल खाता विशिष्ट चेकपॉइंट बहाल करें। हर प्रयास में एक चीज़ बदलें ताकि अगला लॉग पठन कुछ अर्थ रखे।
कनेक्टिविटी वापस पाने के लिए कई बिना दर्ज किए बदलाव करने की इच्छा का विरोध करें। पाँच साथ-साथ संपादनों से ठीक की गई मशीन बाद में समझाई नहीं जा सकती, और अगला अपडेट उनमें से जिसने वास्तव में भार उठाया था उसे फिर ले आएगा।
फिर साक्ष्य के साथ स्थायी नीति तय करें। अगर अपडेट ने ऐसी निर्भरता उजागर की जिसे किसी ने दर्ज नहीं किया, तो सुधार दस्तावेज़ीकरण और एक परीक्षण है, अपडेट बंद करना नहीं। अगर उसने ऐसी सेवा उजागर की जो साफ़-सुथरे ढंग से फिर शुरू नहीं हो सकती, तो सुधार यूनिट में है, समय-सारिणी में नहीं।
शर्त का नाम आते ही तुलना साफ़ तौर पर सुलझ जाती है। स्वतंत्र मार्ग अनुपस्थित अपडेट को संभालने योग्य जोखिम बनाता है। उसका अभाव उसी नीति को अज्ञात रिकवरी समय वाली नियोजित बाधा बना देता है, और कोई भी स्वचालन उस गणित को नहीं बदलता।