VPN सर्वर कॉन्फ़िगरेशन को सुरक्षित रूप से कैसे वापस लें

सर्वर को वापस लेना इस बात का निर्णय है कि कौन-सी परत विफल हुई, फ़ाइलें कॉपी करने का अभ्यास नहीं। कॉन्फ़िगरेशन, क्रेडेंशियल और पैकेज संस्करण अलग-अलग घड़ियों पर चलते हैं, और एक को बहाल करते समय बाकी के अद्यतित रहने से ऐसा होस्ट बनता है जो स्वस्थ दिखता है और असंगत व्यवहार करता है। नीचे दिया क्रम मानता है कि कोई परिवर्तन पहले ही बिगड़ चुका है और आपसे सबसे छोटी सुसंगत स्थिति बहाल करने को कहता है। इसे क्रम से पूरा करें, और आउट-ऑफ़-बैंड पहुँच जाँच को वह चरण मानें जिसे किसी को नहीं छोड़ना चाहिए।

ऐसा चेकपॉइंट बनाएँ जिसे आप वास्तव में बहाल कर सकें

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

सेवा स्थिर होने के बाद, विफल परिवर्तन को ऐसे होस्ट या स्नैपशॉट पर पुनरुत्पादित करें जिसे आप छोड़ सकें। यह खराब कॉन्फ़िगरेशन को खराब पैकेज या समाप्त प्रमाणपत्र से अलग करता है। बहाल किए गए कॉन्फ़िगरेशन को संस्करण नियंत्रण में रखें ताकि अगला चेकपॉइंट किसी ज्ञात कमिट से शुरू हो। अभ्यास का उद्देश्य प्रलेखित अंतिम बिंदु है, स्थायी डाउनग्रेड नहीं।