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 शेलले अर्को फाइल देख्न सक्छ र आत्मविश्वासका साथ गलत उत्तर दिन सक्छ। त्यसपछि ढिलो पोलरलाई फाइल पढ्न दिनुहोस् र यो कहिल्यै त्यसमा नलेख्ने पुष्टि गर्नुहोस्।

हरेक साठी सेकेन्डमा हुने पोलले चेतावनी समेट्छ, र कुनै पनि हुकले त्यो पोलर जीवित छ भन्नेमा भर पर्नु हुँदैन। यी दुई जिम्मेवारीहरू अलग राख्नुहोस् र जुनसुकै पक्ष पुनः तैनाथ भए पनि सङ्ख्या भरपर्दो रहन्छ।