हरेक दिन OpenVPN रिस्टार्ट गर्ने? घडी होइन, विफलता छान्नुहोस्

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

तीन विफलता आकारलाई तीन फरक मालिक चाहिन्छ। पहिले विफलता छान्नुहोस्, त्यसपछि संयन्त्र आफैं आउँछ।

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

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

प्रत्येकको आफ्नै सङ्केत र आफ्नै मालिक छ। जीवन्तता VPN प्रोटोकलको हो, प्रक्रियाको जीवनचक्र सेवा प्रबन्धकको हो, र अनुप्रयोगको स्वास्थ्य साँघुरो अधिकार भएको अनुगमनको हो।

जीवन्तता विकल्पले के गर्न सक्छ र के गर्न सक्दैन

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

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

सेवा प्रबन्धकसँग के छ

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

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

निर्धारित रिस्टार्ट कहिले जायज हुन्छ

समयमा आधारित रिस्टार्ट उचित मर्मत कार्य हुन सक्छ: यसको मालिक, झ्याल, नामित इन्स्टेन्स र स्वतन्त्र प्रवेश मार्ग हुन्छ। तर निश्चित समयमा सबैलाई विच्छेद गर्ने सामान्य विश्वसनीयता नीति भने हुन सक्दैन।

रिस्टार्ट कुनै ज्ञात चुहावट वा अड्किएको अवस्था छलेर जानका लागि हो भने त्यो इकाइको विवरणमा लेख्नुहोस्, नत्र अर्को व्यक्तिले त्यसलाई सधैंका लागि राख्नेछ।

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

सही प्रश्न कति पटक रिस्टार्ट गर्ने होइन, बरु विफलता पहिले कसले थाहा पाउनुपर्छ भन्ने हो।