सर्व्हर रोलबॅक करणे म्हणजे कोणता स्तर अपयशी ठरला याचा निर्णय, फाइल्स कॉपी करण्याचा सराव नाही। कॉन्फिगरेशन, क्रेडेन्शियल्स आणि पॅकेज आवृत्त्या वेगवेगळ्या घड्याळांवर चालतात, आणि एक पुनर्संचयित करताना इतर अद्ययावत राहिल्यास निरोगी दिसणारा पण विसंगत वागणारा होस्ट तयार होतो। खालील क्रम बदल आधीच चुकला आहे असे गृहीत धरतो आणि सर्वात लहान सुसंगत स्थिती पुनर्संचयित करण्यास सांगतो। तो क्रमाने पूर्ण करा, आणि बँडबाहेरील प्रवेश तपासणी हे कोणीही वगळू नये असे पाऊल माना।

तुम्ही खरोखर पुनर्संचयित करू शकता असे चेकपॉइंट घ्या

सेवा सुरू होताना वाचते ते कॉन्फिगरेशन, ते शेवटी पार्स करणाऱ्या आवृत्तीसह नोंदवा। जुन्या आवृत्तीत स्वच्छ लोड झालेली फाइल अपग्रेडनंतर नाकारली जाऊ शकते किंवा गुपचूप दुर्लक्षित होऊ शकते, म्हणून आवृत्ती त्याच नोंदीत येते। कॉन्फिगरेशन ज्या सामग्रीकडे निर्देश करते ती समाविष्ट करा: खाजगी की, प्रमाणपत्र मार्ग, श्रोता व्याख्या आणि सेवा पोहोचण्यायोग्य करणाऱ्या DNS व फायरवॉल नोंदी। पुनर्संचयितीसाठी तुम्ही जतन न केलेली फाइल लागली तर चेकपॉइंट अपूर्ण आहे।

सिस्टम अजून निरोगी असताना प्रत्येक सेटिंगचा मालक नावाने नोंदवा। प्रदाता पॅनेलने स्थापित केलेला मार्ग, होस्ट फायरवॉलने जोडलेला मार्ग आणि क्लायंटना पाठवलेला मार्ग या तीन वेगळ्या वस्तू आहेत, आणि चुकीचा पुनर्संचयित केल्यास इतर दोन जागेवर राहतात। सेटिंग, मालक आणि फाइल मार्गाचा छोटा तक्ता पुरतो।

रद्दीकरणे कॉन्फिगरेशनपासून वेगळी ठेवा

जुने कॉन्फिगरेशन तुम्ही जाणूनबुजून काढलेले उपकरण गुपचूप पुन्हा जोडू शकते, ज्यामुळे पुनर्प्राप्ती सुरक्षा घट होते। नेटवर्क धोरण पुनर्संचयित करताना सध्याची रद्दीकरण यादी आणि अक्षम खाती जपून ठेवा, नंतर सेवा क्लायंट स्वीकारण्यापूर्वी ती पुन्हा लागू करा।

ओळखीची स्थिती स्वतःच्या पुराव्यांसह स्वतंत्र रोलबॅक म्हणून पाहा। प्रमाणपत्र रद्दीकरण फाइली, खाते अक्षम करणे आणि MFA नोंदणी डेमन कॉन्फिगरेशनच्याच जागी क्वचित असतात, आणि कॉन्फिगरेशन पुनर्संचयित त्यांना स्पर्श करत नाही। काय टिकले पाहिजे हे कळण्यासाठी आधी सध्याची स्थिती तपासा। पुनर्संचयितीनंतर काढलेली ओळख अजूनही जोडू शकत नाही याची खात्री करा।

बोगदा अपयशी झाल्यावर होस्टपर्यंत पोहोचा

बदलल्या जाणाऱ्या घटकावर अवलंबून नसलेला मार्ग मशीनपर्यंत उघडा। हायपरव्हायझर कन्सोल, वेगळ्या इंटरफेसवरील व्यवस्थापन पत्ता किंवा सिरियल कन्सोल हे सर्व योग्य आहेत; बोगद्यातून नेलेले SSH सत्र नाही। प्रवेशाचा एकमेव मार्ग तुम्ही पुन्हा सुरू करणार असलेला VPN असेल, तर चुकीचा मार्ग किंवा फायरवॉल नियम तो दुरुस्त करण्याची क्षमता हिरावून घेतो। बदलापूर्वी पर्यायी मार्ग तपासा, नंतर नाही। त्यातून एकदा लॉग इन करा, sudo चालत असल्याची खात्री करा आणि वापरलेला नेमका पत्ता नोंदवा।

चाचणी सोपी आहे: पर्यायी मार्गाने जोडलेले असताना बोगदा खाली घ्या आणि सत्र टिकते का ते पहा। तुटल्यास, अडकण्यापूर्वीच तुम्ही बिघाड शोधला आहे।

एकच सुधारणा लागू करा आणि ती कधी अमलात येते ते जाणून घ्या

सेवेच्या reload किंवा restart दस्तऐवजांचा वापर करा आणि कोणत्या सूचना कोणत्या क्षणी वाचल्या जातात ते शोधा। काही मूल्ये reload वेळी लागू होतात, इतर नवीन सत्र किंवा प्रक्रिया सुरू झाल्यावरच, म्हणून फाइल संपादन चालू स्थितीबद्दल काहीही सिद्ध करत नाही। नवीन फाइल जुन्या रनटाइम स्थितीसोबत मिसळण्याऐवजी एकच सुधारणा पुनर्संचयित करा। शंका असल्यास सेवेचा संपूर्ण पुनःप्रारंभ अर्धवट reload पेक्षा सोपा समजावता येतो।

निवडण्यापूर्वी युनिट व्याख्या तपासा: systemctl show -p ExecReload openvpn@server reload हुक अस्तित्वात आहे का ते सांगते। नंतर सुधारणा लागू करा आणि दुसरे काही बदलण्यापूर्वी जर्नलमधील पहिल्या नवीन त्रुटी वाचा।

पडताळा, नोंदवा आणि नंतर तपास करा

एक अधिकृत क्लायंट जोडा आणि सेवा कशासाठी आहे ते वापरून पहा: नाव निराकरण, पुन्हा जोडणी आणि जे अनुप्रयोग अयशस्वी झाले। रद्द केलेल्या ओळखीला अजूनही नकार दिला जातो याची खात्री करा। तुम्ही पुनर्संचयित केलेली सुधारणा, वेळ आणि कारण नोंदवा, कारण पुढील ऑपरेटरला तिन्ही लागतील। कोणीही नोंद न केलेला रोलबॅक पुढच्या वेळी सेवा वाईट वागल्यास कोडे बनतो।

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

सेवा स्थिर झाल्यावर, अयशस्वी बदल तुम्ही टाकून देऊ शकता अशा होस्ट किंवा स्नॅपशॉटवर पुन्हा तयार करा। यामुळे खराब कॉन्फिगरेशन खराब पॅकेज किंवा कालबाह्य प्रमाणपत्रापासून वेगळे होते। पुनर्संचयित कॉन्फिगरेशन आवृत्ती नियंत्रणात ठेवा जेणेकरून पुढील चेकपॉइंट ज्ञात कमिटपासून सुरू होईल। सरावाचा हेतू नोंदवलेला अंतिम बिंदू आहे, कायमस्वरूपी डाउनग्रेड नाही।

संबंधित लेख