OpenVPN up वर सेवा पुन्हा सुरू करणे: हुक tun0.device पेक्षा चांगले

अवलंबित सेवेला tun0.device शी जोडणे टनेलची सदस्यता घेण्यासारखे वाटते, आणि तसे नाही. डिव्हाइस युनिट इंटरफेस अस्तित्वात असल्याचे प्रतिबिंबित करते, जे अयशस्वी कनेक्शन आणि त्यानंतरच्या पुनर्कनेक्शनमध्येही खरे राहू शकते. मग सेवा चुकीच्या क्षणी कार्य करते, किंवा कधीच करत नाही, इंटरफेस दरम्यान गायब झाला का यावर अवलंबून. तुम्हाला खरोखर महत्त्वाची असलेली घटना वर्णन करणारा हुक तोच आहे जो OpenVPN कॉल करते, systemd ज्याचा अंदाज लावते तो नाही.

ट्रिगर निवडण्यापूर्वी सेवेला कोणती अट आवश्यक आहे ते ठरवा, कारण तिन्ही उमेदवार परस्पर बदलण्यायोग्य नाहीत.

डिव्हाइस युनिट प्रत्यक्षात काय मागोवा घेते

systemd नेटवर्क इंटरफेसबद्दल कर्नेलच्या दृष्टिकोनातून डिव्हाइस युनिट तयार करते, म्हणून इंटरफेस दिसल्यावर tun0.device सक्रिय होते आणि काढून टाकल्यावर निष्क्रिय होते. persist-tun सह, मऊ रीस्टार्ट इंटरफेसला त्याच्या जागी ठेवतो, म्हणून युनिट कधीही फ्लॅप होत नाही आणि त्याला जोडलेले काहीही ट्रिगर होत नाही. टिकाऊपणाशिवायही, युनिट मार्ग, DNS किंवा दूरचे टोक प्रतिसाद देते का याबद्दल काहीही सांगत नाही.

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

up, route-up आणि up-restart वेगवेगळे अर्थ देतात

TUN/TAP उपकरण उघडल्यानंतर आणि इंटरफेस कॉन्फिगर झाल्यानंतर up चालते, जो नियुक्त पत्ता बांधणाऱ्या श्रोत्यासाठी योग्य क्षण आहे. मार्ग स्थापित झाल्यानंतर, कॉन्फिगर केलेल्या मार्ग विलंबाच्या अधीन राहून route-up चालते, आणि मार्ग टप्पा पूर्ण होणे आवश्यक असलेल्या कामासाठी योग्य आहे. दोन्हीपैकी कोणतेही दूरचा अनुप्रयोग प्रतिसाद देतो हे सिद्ध करत नाही. त्यांच्यातील निवड ही सेवेला काय आवश्यक आहे याचा प्रश्न आहे, कोणता हुक अधिक पूर्ण वाटतो हा नाही.

persist-tun सह, रीस्टार्ट उपकरणाचा पुनर्वापर करतात, म्हणून up-restart सेट नसल्यास up पुन्हा चालत नाही. तो पर्याय दस्तऐवजीकृत रीस्टार्ट जीवनचक्रासाठी up स्क्रिप्ट सक्षम करतो, आणि त्याचे वातावरण पहिल्या सुरुवातीच्या तुलनेत कमी केलेले आहे. संपूर्ण वातावरण गृहीत धरणारी स्क्रिप्ट पहिल्या कनेक्शनवर कार्य करते आणि पुढच्या वेळी अयशस्वी होते.

क्रिया प्रतीक्षा न करता पाठवा

systemctl restart समकालिकपणे कॉल करणारा हुक, ज्याचा क्रम टनेलची प्रतीक्षा करतो अशा युनिटशी डेडलॉक होऊ शकतो. systemctl --no-block try-restart vpn-dependent.service कार्य रांगेत ठेवतो आणि परत येतो, ज्यामुळे हुक आपण प्रतिक्रिया देत असलेले कनेक्शन ब्लॉक करत नाही. try-restart फक्त चालू असलेल्या युनिटवर कार्य करते, तर restart निष्क्रिय युनिटलाही सुरू करते; सवयीने नाही तर जाणीवपूर्वक निवडा.

रांगेत ठेवणे हे पडताळणी नाही. कार्य स्वीकारताच हुक यश परत करतो, म्हणून तपासणी लक्ष्य युनिटच्या जर्नलमध्ये किंवा त्याच्या वास्तविक श्रोता स्थितीत व्हायला हवी.

रीस्टार्ट धोरण युनिटमध्ये असते, हुकमध्ये नाही

RemainAfterExit=yes असलेले oneshot युनिट त्याचा आदेश संपल्यानंतरही सक्रिय राहते, आणि दुसरी सुरू करण्याची विनंती काहीही करत नाही कारण systemd ते आधीच सुरू झालेले मानते. हे अशा गुणधर्माचे आहे ज्याभोवती रचना करायची असते, वारंवार सुरू करण्याच्या कॉल्सने टाळायचा दोष नाही. क्रिया प्रत्येक कनेक्शनवर चालली पाहिजे असेल, तर युनिटला ते परवानगी देणारा आकार हवा.

After= युनिटचा क्रम ठरवते, आणि BindsTo= आयुष्य जोडते, पण यातील कोणतेही 'VPN पुन्हा कनेक्ट होताच हे पुन्हा सुरू कर' असा अर्थ देत नाही. टनेलला जोडलेले युनिट टनेल थांबल्यावर थांबते; टनेल परत आल्यावर ते स्वतःला पुन्हा सुरू करत नाही, जोपर्यंत काही ते पुन्हा सुरू करत नाही.

एक नाही, तीन पुनर्कनेक्शनची चाचणी करा

कोल्ड बूट, पूर्ण क्लायंट रीस्टार्ट आणि मऊ पुनर्कनेक्शन प्रत्येकजण वेगळा मार्ग सरावतात. मऊ पुनर्कनेक्शन हेच गहाळ up-restart, कमी झालेले वातावरण किंवा कधीही निष्क्रिय न झालेले डिव्हाइस युनिट उघड करते. तिन्ही चालवा आणि दोन्ही दिशा पुष्टी करा: टनेल वर आल्यावर सेवा कार्य करते, आणि Wi-Fi रोमिंगसारख्या असंबंधित लिंक बदलांवर ती पुन्हा सुरू होत नाही.

अवलंबित सेवा तुमचे स्वतःचे प्रशासकीय प्रवेश घेऊन चालत असेल तर स्वतंत्र पुनर्प्राप्ती मार्ग ठेवा. ज्या हुकमधून तुम्ही जोडलेले आहात ते पुन्हा सुरू करणारा हुक हा तुम्हाला बाहेर कुलूपबंद करू शकणारा बदल आहे.