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 रोमिङजस्ता असम्बन्धित लिङ्क परिवर्तनमा यो पुनः सुरु हुँदैन।

निर्भर सेवाले तपाईंको आफ्नै प्रशासनिक पहुँच बोकेको बेला स्वतन्त्र रिकभरी मार्ग राख्नुहोस्। तपाईं जसबाट जोडिनुभएको छ त्यसलाई पुनः सुरु गर्ने हुक त्यस्तो परिवर्तन हो जसले तपाईंलाई बाहिर ताला लगाउन सक्छ।