up आणि down हुक्सने OpenVPN क्लायंटचा अपटाइम कसा मोजायचा

एक डॅशबोर्ड विचारतो की कनेक्शन किती वेळापासून सुरू आहे, आणि OpenVPN ते देत नाही। क्लायंटला माहीत असते की त्याचा बोगदा कधी वर आला, पण सेशनची स्थिती जाण्यापूर्वी कोणी तो क्षण नोंदवला तरच। समर्थित जागा up हुक आहे, आणि साठवण्यासारखे मूल्य म्हणजे फॉर्मेट केलेली स्ट्रिंग नाही तर कच्चा epoch सेकंद। त्यानंतर सर्व गणित आहे, शिवाय संख्या प्रामाणिक राहते का हे ठरवणारे काही क्रम-नियम।

हुक्स प्रत्यक्षात चालतात याची खात्री करा

त्याभोवती काहीही रचण्यापूर्वी हुक चालतो हे सिद्ध करा। किमान क्लायंट कॉन्फिगरेशनला script-security 2 आणि स्पष्ट मार्ग up व down लागतात; सुरक्षा ओळ नसल्यास OpenVPN स्क्रिप्ट चालवण्यास नकार देते आणि ते स्पष्ट सांगते। त्याच वेळी up-restart आणि down-pre जोडा, म्हणजे रीस्टार्ट आणि तोडणीचे मार्ग अंदाजे वागतील।

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

हुक कोणत्या वापरकर्त्याच्या रूपात चालतो ते तपासा। user आणि group सेट असल्यास OpenVPN स्क्रिप्ट चालवण्यापूर्वी विशेषाधिकार सोडते, त्यामुळे root लिहू शकणारी डिरेक्टरी हुकसाठी बंद असू शकते। मार्ग तुमच्या शेलच्या दृष्टिकोनातून नव्हे, सेवेच्या दृष्टिकोनातून निवडा।

एक epoch मूल्य नोंदवा आणि ते जाणीवपूर्वक पुसा

up हुकला एक ओळ लागते, date +%s > /run/openvpn-client.started, प्रत्येक इन्स्टन्ससाठी मार्ग जुळवून। epoch मूल्य पुढे भाषा, समय क्षेत्र आणि फॉर्मॅटचे प्रश्न टाळते, आणि ही तीच संख्या आहे जी मॉनिटरिंग एजंट आपल्या घड्याळाशी तुलना करू शकतो।

पुसणे लिहिण्याइतकेच महत्त्वाचे आहे। down हुकने फाइल रिकामी करावी किंवा काढून टाकावी, आणि down-pre हे इंटरफेस बंद होण्यापूर्वी करते, ज्यामुळे आधीच गेलेल्या बोगद्याचे वर्णन फाइल करते अशी खिडकी नाहीशी होते। up-restart नंतर अंतर्गत रीस्टार्टवर स्टॅम्प ताजा करते, मूळ मूल्य जागी सोडण्याऐवजी। ती जोडी नसल्यास ping कालबाह्यानंतरचा रीस्टार्ट बोगदा पुन्हा स्थिर होईपर्यंत वाढत जाणारी संख्या देतो।

योग्य आयुष्याची जागा निवडा। /run खालील फाइल रीबूटवर नाहीशी होते, जे वास्तवाशी जुळते, तर /tmp खालील फाइल अप्रत्याशितपणे साफ होऊ शकते आणि कॉन्फिगरेशन डिरेक्टरीतील फाइल दिशाभूल करणाऱ्या पद्धतीने टिकते। परवानग्या अशा ठेवा की फक्त सेवा वापरकर्ता आणि मॉनिटरिंग वाचक ती वाचू शकतील।

लॉग ओळींवर विश्वास न ठेवता अपटाइम मोजा

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

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

तपासणी दुसऱ्या होस्टवर चालत असेल तर कालावधीऐवजी टाइमस्टॅम्प पाठवा, म्हणजे वाचक आपले घड्याळ लावेल। मग लहान ऋणात्मक निकाल तुटलेला हुक नव्हे तर घड्याळातील फरक म्हणून वाचला जातो।

पुनर्जोडणी, रीस्टार्ट आणि अनेक इन्स्टन्स समाविष्ट करा

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

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

सर्व्हरच्या बाजूला, स्थिती फाइल प्रत्येक क्लायंटसाठी connected-since मूल्य ठेवते, जे वेगळ्या प्रश्नाचे उत्तर देते: सर्व्हरने त्या पीअरला शेवटी कधी पाहिले। ते बदली म्हणून नव्हे, क्रॉस-चेकसाठी वापरा, कारण ते वर्णन करणाऱ्या सेशनसह नाहीसे होते। दोन्हीपैकी कोणतेही मापन बोगद्यामागील अनुप्रयोगाच्या आरोग्याबद्दल काहीही सांगत नाही।

क्रमातील बग पकडणाऱ्या तीन तपासण्या चालवा

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

प्रत्येक साठ सेकंदाला एक पोल इशाऱ्यांची पूर्तता करतो, आणि कोणत्याही हुकने तो पोलर जिवंत आहे यावर अवलंबून राहू नये। या दोन जबाबदाऱ्या वेगळ्या ठेवा आणि कोणतीही बाजू पुन्हा तैनात झाली तरी संख्या विश्वासार्ह राहते।