सर्भर रोलब्याक गर्नु भनेको कुन तह असफल भयो भन्ने निर्णय हो, फाइल प्रतिलिपि गर्ने अभ्यास होइन। कन्फिगरेसन, प्रमाणहरू र प्याकेज संस्करणहरू फरक फरक घडीमा चल्छन्, र एउटा पुनःस्थापित गर्दा अरू अद्यावधिक रहेमा स्वस्थ देखिने तर असंगत व्यवहार गर्ने होस्ट बन्छ। तलको क्रमले परिवर्तन पहिले नै बिग्रिसकेको मान्छ र सबैभन्दा सानो सुसंगत अवस्था पुनःस्थापित गर्न भन्छ। यसलाई क्रममा पूरा गर्नुहोस्, र ब्यान्ड बाहिरको पहुँच जाँचलाई कसैले पनि नछोड्नुपर्ने चरण मान्नुहोस्।

तपाईंले साँच्चै पुनःस्थापित गर्न सक्ने चेकपोइन्ट लिनुहोस्

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

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

सम्बन्धित लेखहरू