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

जो अब भी आपके पास है, उसे दोहराएँ

सामने की कंसोल स्क्रीन से शुरू करें और उन रास्तों की सूची बनाएँ जो टनल पर निर्भर नहीं हैं। सीरियल या VNC सत्र वाला प्रदाता का वेब कंसोल एक है। अलग नेटवर्क पर प्रबंधन इंटरफ़ेस दूसरा है। भौतिक पहुँच तीसरा है, और यही वह है जिसकी अनुपस्थिति लोग सबसे बुरे पल में पाते हैं।

PathDepends onUsually fails when
Provider consoleAccount access and the provider's own APICredentials live in a wiki only reachable over the tunnel
Management subnetA second interface and its own routingThe bad change was a global route or firewall policy
Second tunnelA different listener, port and credentialsBoth listeners were changed in the same edit
Physical or local consoleBeing in the buildingNobody has been in the building for a year

तीसरे स्तंभ को अमूर्तता नहीं, विफलताओं की सूची की तरह पढ़ें। उन रास्तों में से दो आमतौर पर एक ही कारण से विफल होते हैं। तालिका वही तरीका है जिससे आप इसे बाधा के आपको समझाने से पहले नोटिस करते हैं।

स्वतंत्रता निर्भरताओं का प्रश्न है

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

श्रृंखला में नीचे उतरें और हर चरण की ज़रूरत का नाम दें। नेटवर्क पहुँच, नाम विश्लेषण, प्रमाणीकरण स्रोत और स्वयं प्रबंधन सेवा चार अलग निर्भरताएँ हैं, और जो रास्ता इनमें से कोई भी साझा करता है वह वही विफलता विरासत में पाता है।

जिस रास्ते की कभी परीक्षा नहीं हुई वह अपने संदेह का हकदार है। महीनों से न खोला गया कंसोल ईमेल से पासवर्ड रीसेट माँग सकता है, और वह मेलबॉक्स उस मशीन पर हो सकता है जहाँ आप नहीं पहुँचते। सब कुछ चलते समय रास्ता परखें, और शांत दोपहर में आपको यह मिलेगा।

एक नियंत्रित बदलाव के लिए दूसरा रास्ता इस्तेमाल करें

कंसोल से स्नैपशॉट लें या जिस कॉन्फ़िगरेशन को संपादित करने जा रहे हैं उसकी प्रतिलिपि बनाएँ। एक चीज़ बदलें। सेवा को फिर लोड करें और कुछ और छूने से पहले परिणाम पढ़ें, क्योंकि एक साथ दो बदलाव रिकवरी को प्रयोग में बदल देते हैं।

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

याद से नहीं, रिकवरी रास्ते से जाँचें

मायने रखने वाली जाँच यह है कि सामान्य रास्ता लौटता है या नहीं, और रिकवरी सत्र वही जगह है जहाँ आप इसे क्रम में पुष्ट करते हैं:

systemctl status openvpn-server@server --no-pager
ss -lntup | grep -E ':(1194|443)\b'
nft list ruleset | sed -n '1,40p'
journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30

पहले सेवा की स्थिति पढ़ें, फिर श्रोता, फिर नियम, फिर जर्नल। श्रोता के बिना चल रही सेवा सेवा कॉन्फ़िगरेशन की ओर इशारा करती है, जबकि पहुँच योग्य नियमों के बिना श्रोता फ़िल्टरिंग की ओर। क्रम मायने रखता है क्योंकि हर चरण अगले को संकीर्ण करता है, और जर्नल पर कूदना आमतौर पर ऐसी त्रुटियाँ पढ़ना है जो लक्षण बताती हैं, कारण नहीं।

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

इन्वेंटरी अद्यतन रखें

जब लोग या अधोसंरचना बदलें तो पहुँच सूची की समीक्षा करें। सब कुछ चलते समय रिकवरी रास्ता परखें। जिन खातों का पिछले पुनर्गठन के बाद किसी ने उपयोग नहीं किया उन्हें सेवानिवृत्त करें। दो पुराने खाते और एक समाप्त प्रमाणपत्र मंगलवार को छोटी सफ़ाई और रविवार को बाधा हैं।

दर्ज करें कि कौन हर रास्ता इस्तेमाल कर सकता है, वह क्या अनुमति देता है और क्रेडेंशियल कैसे घुमाए जाते हैं। बिना मालिक वाला रिकवरी रास्ता भूला हुआ प्रवेशद्वार बन जाता है, जो बाहर बंद होने से अलग प्रकार की विफलता है।

संबंधित लेख