दररोज OpenVPN पुन्हा सुरू करायचे? घड्याळ नाही, अपयश निवडा

तुम्हाला एक cron कार्य वारसाने मिळते जे दररोज 04:10 वाजता OpenVPN पुन्हा सुरू करते, आणि ते एका वर्षापासून सर्वकाही स्थिर ठेवत आहे। पण ते ठरलेल्या वेळी निरोगी बोगदाही तोडते आणि दुपारच्या जेवणाच्या वेळी प्रत्यक्षात होणाऱ्या व्यत्ययासाठी काहीही करत नाही। कॅलेंडरनुसार पुन्हा सुरू करणे हा देखभालीचा निर्णय आहे। पुनर्प्राप्ती ही विशिष्ट ट्रिगर असलेली वेगळी रचना आहे।

तीन अपयशाच्या स्वरूपांना तीन वेगळे मालक लागतात। आधी अपयश निवडा, यंत्रणा आपोआप येईल।

तीन अपयशे, तीन मालक

पीअर गेला तरी बोगदा सुरू असू शकतो: प्रक्रिया चालू आहे, इंटरफेस अस्तित्वात आहे, आणि त्यातून काहीही उपयुक्त जात नाही। पीअर ठीक असतानाही प्रक्रिया मृत असू शकते, आणि तेव्हा ज्याने ती सुरू केली तेच तिला परत आणू शकते। बोगद्यामागील अनुप्रयोग बोगदा आणि पीअर दोन्ही निरोगी असताना बिघडू शकतो, आणि तेव्हा क्लायंट पुन्हा सुरू केल्यास कारणाला स्पर्श न करता व्यत्यय वाढतो। या तीन प्रकरणांचे विभाजन हाच संपूर्ण निर्णय आहे।

प्रत्येकाचा स्वतःचा संकेत आणि स्वतःचा मालक आहे। जिवंतपणा VPN प्रोटोकॉलचा आहे, प्रक्रियेचे जीवनचक्र सेवा व्यवस्थापकाचे आहे, आणि अनुप्रयोगाचे आरोग्य अरुंद अधिकार असलेल्या देखरेखीचे आहे।

जिवंतपणाचा पर्याय काय करू शकतो आणि काय करू शकत नाही

keepalive हा सहाय्यक आहे जो ping आणि ping-restart जोडीत विस्तारतो, जसे लिंक-पर्याय संदर्भ सांगतो, आणि तो तयार करणाऱ्या वेळमर्यादा सर्व्हर आणि क्लायंटवर सारख्याच नाहीत। सर्व्हरने पाठवलेली मूल्ये क्लायंटने स्थानिक पातळीवर सेट केलेली मूल्येही बदलू शकतात, म्हणून स्थानिक फाइलमध्ये बरोबर दिसणारी वेळमर्यादा प्रत्यक्षात लागू असलेली नसेल।

त्यामुळे हे हरवलेल्या पीअरसाठी योग्य साधन आणि मृत प्रक्रियेसाठी अयोग्य साधन आहे, कारण बाहेर पडलेली प्रक्रिया स्वतःचे टाइमर चालवू शकत नाही। बोगद्यामागील अनुप्रयोग उत्तर देतो की नाही याबद्दलही ते काही सांगत नाही, कारण देवाणघेवाण दोन VPN टोकांदरम्यान होते। भूमिका, अपेक्षित व्यत्यय आणि पुनर्प्रमाणीकरणाचे वर्तन तपासल्याशिवाय दुसऱ्या तैनातीतून वेळमर्यादांची जोडी कॉपी करणे हाच स्थिर बोगदा थरथरण्यास सुरुवात करण्याचा मार्ग आहे।

सेवा व्यवस्थापकाकडे काय आहे

डीमन बाहेर पडल्यास, ज्याने ते सुरू केले तो व्यवस्थापक पुढे काय होईल हे ठरवतो। अपयशावर आधारित पुन्हा सुरू करण्याचे धोरण, विलंब आणि सुरुवातीच्या दराची मर्यादा यासह, क्रॅश लूप फोर्क बॉम्ब न बनवता हाताळते। ती सेटिंग्ज प्रक्रियेच्या निकालांना आणि वेळमर्यादांना प्रतिसाद देतात, आणि जिवंत पण निरुपयोगी प्रक्रिया ओळखत नाहीत। हे व्यापक धोरणाने भरून काढायची त्रुटी नाही; ही जीवनचक्र आणि जिवंतपणा यांमधील सीमा आहे।

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

नियोजित पुन्हा सुरू करणे कधी न्याय्य आहे

वेळेनुसार पुन्हा सुरू करणे ही वाजवी देखभाल कृती असू शकते: तिला मालक, खिडकी, नाव असलेली उदाहरण आणि स्वतंत्र प्रवेशमार्ग असतो। पण ठरलेल्या वेळी सर्वांना डिस्कनेक्ट करणारे सर्वसाधारण विश्वासार्हता धोरण ते असू शकत नाही।

पुन्हा सुरू करणे ज्ञात गळती किंवा अडकलेली स्थिती टाळण्यासाठी असेल, तर ते युनिटच्या वर्णनात लिहा, अन्यथा पुढचा माणूस ते कायम ठेवेल।

महत्त्वाची प्रकरणे तपासा: प्रक्रिया सुरू असताना पीअर गायब होतो, प्रक्रिया बाहेर पडते, पुन्हा प्रयत्नासाठी नवीन क्रेडेन्शियल्स लागतात, आणि अनुप्रयोग बिघडलेला असताना बोगदा परत येतो। कोणता घटक प्रतिसाद देतो आणि मागे कोणती स्थिती सोडतो ते पहा।

योग्य प्रश्न हा नाही की किती वेळा पुन्हा सुरू करायचे, तर हा आहे की अपयशाची नोंद आधी कोणी घ्यायला हवी।