एका टाइमआउटनंतर तुमचा 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 सह उपकरण सत्रापेक्षा जास्त जगते आणि काहीही वाहत नसतानाही तपासणी निरोगी असल्याचे सांगते।