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 शेल दूसरी फ़ाइल देख सकता है और आत्मविश्वास से ग़लत जवाब दे सकता है। फिर एक धीमे पोलर को फ़ाइल पढ़ने दें और पुष्टि करें कि वह उसमें कभी नहीं लिखता।

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