OpenVPN up पर सेवा को फिर से चालू करना: hooks 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 रोमिंग जैसे असंबंधित लिंक परिवर्तनों पर वह फिर से शुरू नहीं होती।

जब निर्भर सेवा आपकी अपनी प्रशासनिक पहुँच लेकर चलती है तो एक स्वतंत्र रिकवरी पथ रखें। जिस हुक से आप जिस चीज़ के माध्यम से जुड़े हैं उसे फिर से शुरू करता है, वह ऐसा परिवर्तन है जो आपको बाहर लॉक कर सकता है।