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