OpenVPN को रोज़ रीस्टार्ट करें? घड़ी नहीं, विफलता चुनें

आपको एक cron कार्य विरासत में मिलता है जो हर दिन 04:10 पर OpenVPN को रीस्टार्ट करता है, और वह एक साल से चीज़ों को स्थिर रख रहा है। वह एक तय घंटे पर स्वस्थ टनल को भी डिस्कनेक्ट करता है और उस रुकावट के लिए कुछ नहीं करता जो असल में दोपहर के खाने के समय होती है। कैलेंडर के हिसाब से रीस्टार्ट एक रखरखाव निर्णय है। रिकवरी एक अलग डिज़ाइन है, जिसका एक खास ट्रिगर होता है।

तीन विफलता-आकारों को तीन अलग मालिक चाहिए। पहले विफलता चुनें, और तंत्र खुद-ब-खुद आ जाएगा।

तीन विफलताएँ, तीन मालिक

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

हर एक का अपना संकेत और अपना मालिक है। जीवंतता VPN प्रोटोकॉल की है, प्रोसेस का जीवनचक्र सेवा प्रबंधक का है, और ऐप्लिकेशन का स्वास्थ्य संकीर्ण अधिकार वाली निगरानी का है।

जीवंतता वाला विकल्प क्या कर सकता है और क्या नहीं

keepalive एक सहायक है जो ping और ping-restart की जोड़ी में फैलता है, जैसा लिंक-विकल्प संदर्भ बताता है, और यह जो समय-सीमाएँ बनाता है वे सर्वर और क्लाइंट पर एक जैसी नहीं होतीं। सर्वर द्वारा भेजे गए मान उसे भी बदल सकते हैं जो क्लाइंट ने स्थानीय रूप से सेट किया है, इसीलिए स्थानीय फ़ाइल में सही दिखने वाली समय-सीमा वह नहीं हो सकती जो लागू है।

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

सेवा प्रबंधक के पास क्या है

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

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

निर्धारित रीस्टार्ट कब जायज़ है

तय समय पर रीस्टार्ट उचित रखरखाव कार्रवाई हो सकता है: उसका एक मालिक, एक खिड़की, एक नामित इंस्टेंस और स्वतंत्र प्रवेश मार्ग होता है। वह जो नहीं हो सकता वह है सामान्य विश्वसनीयता नीति जो तय घंटे पर सबको डिस्कनेक्ट भी कर दे।

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

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

सही सवाल यह नहीं है कि कितनी बार रीस्टार्ट करें, बल्कि यह है कि विफलता को पहले किसने नोटिस करना चाहिए।