एक टाइमआउट के बाद आपका OpenVPN क्लाइंट क्यों बंद रह जाता है

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

यूनिट ने वास्तव में क्या किया, वहीं से शुरू करें, मॉनिटरिंग जो दावा करती है वहाँ से नहीं। systemctl status openvpn-client@office और journalctl -u openvpn-client@office -n 50 बाहर निकलने का कारण और क्लाइंट द्वारा जाने से पहले लिखी गई अंतिम पंक्ति दिखाते हैं।

किसी के नोटिस करने से पहले प्रक्रिया बाहर निकल गई

बिना त्रुटि गायब होने वाला क्लाइंट सामान्यतः जानबूझकर बाहर निकला होता है। यह व्यवहार प्रोफ़ाइल तय करता है, सेवा प्रबंधक नहीं: ping-exit सामने वाले के जवाब देना बंद करते ही प्रक्रिया समाप्त कर देता है, जबकि ping-restart प्रक्रिया रखता है और उसके भीतर फिर से जुड़ता है। सत्र सीमाएँ और निष्क्रियता टाइमर बाहर से वही तस्वीर बनाते हैं: न टनल और न अलार्म।

दो ping निर्देश एक ही प्रोफ़ाइल में साथ नहीं रह सकते, इसलिए एक चुनें और चयन दर्ज करें। सर्वर को भी देखें, क्योंकि उसका अपना ping-exit क्लाइंट की मांग चाहे जो हो, सत्र बंद कर देता है, और किसने वह निर्णय लिया यह केवल सर्वर लॉग में दर्ज होता है।

ping-exit और ping-restart के बीच चुनाव

ऐसे लैपटॉप या दूरस्थ साइट के लिए ping-restart चुनें जिसे स्वयं ठीक होना चाहिए, और ping-exit उन मामलों के लिए रखें जहाँ मृत टनल को प्रक्रिया रोकनी हो ताकि कोई और उस पर कार्य कर सके। संख्याएँ संबंध से कम महत्वपूर्ण हैं: ping 10 के साथ ping-restart 60 का अर्थ है जाँच से पहले दस सेकंड का मौन और रीस्टार्ट से पहले साठ, जो हानि वाले मोबाइल लिंक पर आक्रामक और वायर्ड लिंक पर उचित है। कारण पंक्ति के बगल में लिखें, अन्यथा अगला पाठक मान लेगा कि डिफ़ॉल्ट मान जानबूझकर थे।

फिर पुष्टि करें कि बाहर वास्तव में प्रक्रिया ही निकली है। टनल मृत होने पर सक्रिय होने की सूचना देने वाली यूनिट एक अलग विफलता है, जिस पर नीचे चर्चा है।

ऐसी निगरानी जो यूनिट को वास्तव में रीस्टार्ट करे

systemd होस्ट पर सबसे छोटा टिकाऊ परिवर्तन एक drop-in फ़ाइल है: Restart=on-failure और RestartSec=10, जो /etc/systemd/system/[email protected]/restart.conf फ़ाइल में हैं। drop-in तभी पढ़ा जाता है जब systemd अपनी परिभाषाएँ फिर से लोड करता है, इसलिए उसके बाद systemctl daemon-reload चलाएँ। मान पहुँच गया मानने के बजाय systemctl show -p Restart -p ExecMainStatus openvpn-client@office से सत्यापित करें। फ़ाइल नाम का इंस्टेंस वही प्रोफ़ाइल होना चाहिए जिसे यूनिट वास्तव में लोड करती है, इसलिए office के लिए लिखी फ़ाइल openvpn-client@home के लिए कुछ नहीं करती।

on-failure एक मामले को अनदेखा करता है: शून्य स्थिति वाला स्वच्छ निकास। कुछ टियरडाउन पथ ऐसे ही समाप्त होते हैं, इसलिए मैन पेज के शब्दों पर भरोसा करने के बजाय दर्ज स्थिति पढ़ें। यदि आपका क्लाइंट शून्य के साथ हार मानता है, तो आपको Restart=always चाहिए, और कीमत यह है कि वास्तव में टूटी प्रोफ़ाइल तब तक बार-बार लौटती रहती है जब तक स्टार्ट दर सीमा सक्रिय न हो और जर्नल भर न जाए।

Restart=always जानबूझकर रोकने के बाद भी सक्रिय होता है। रखरखाव के लिए systemctl stop का उपयोग करें, और यदि काम करते समय यूनिट को बंद रहना हो तो उसे मास्क करें।

टनल बंद होने के दौरान लीक पकड़ें

निगरानी टनल को वापस लाती है; यह नहीं रोकती कि टनल के न होने पर ट्रैफ़िक बाहर जाए। persist-tun पुनः कनेक्शन के बीच डिवाइस और उसके रूट रखता है, जो सुविधाजनक है और एक खिड़की खोलता है। डिवाइस बचा रहता है, रूट अब भी उसी की ओर हैं, और पैकेट बिना सुरक्षा और बिना रिपोर्ट के बाहर बहते हैं। यह नीति का चुनाव है, तटस्थ डिफ़ॉल्ट नहीं।

जब किसी होस्ट को बिना सुरक्षा वाले पैकेट भेजने की बिल्कुल अनुमति न हो, तो केवल फ़ायरवॉल ही इसकी गारंटी दे सकता है। टनल इंटरफ़ेस और VPN सर्वर के पते को अनुमति देकर बाकी सब गिराने वाला आउटपुट नियम क्लाइंट के मरने के बाद भी लागू रहता है, और क्लाइंट के अपने कॉन्फ़िगरेशन में कुछ भी ऐसा नहीं है जो उस ट्रैफ़िक को फ़िल्टर कर सके जो क्लाइंट नहीं ढो रहा।

क्लाइंट को जानबूझकर रोककर इसे जाँचें। systemctl stop openvpn-client@office चलाएँ, फिर curl -m 5 https://example.com, जो भौतिक लिंक पर सफल होने के बजाय विफल होना चाहिए। सफलता का अर्थ है कि फ़ायरवॉल नियम गायब है या बहुत अधिक अनुमति देने वाला है।

फिर से कनेक्ट करें, पुष्टि करें कि टनल फिर ट्रैफ़िक ढो रहा है, और तभी जाँच को मॉनिटरिंग में जोड़ें। cron से ip addr द्वारा tun डिवाइस के लिए पूछताछ करना सबसे अधिक विफल होने वाली निगरानी है, क्योंकि persist-tun के साथ डिवाइस सत्र से अधिक जीवित रहता है और जब कुछ भी नहीं ढोया जा रहा हो तब भी प्रोब स्वास्थ्य बताता है।