क्या OpenVPN हुक स्क्रिप्ट उस टनल का उपयोग कर सकती है जो उसने अभी बनाई है?

हुक स्क्रिप्ट टनल के दूसरी ओर पहुँच पाती है या नहीं, यह तीन शर्तों पर निर्भर है: वह किस घटना से जुड़ी है, स्क्रिप्ट चलते समय OpenVPN अभी अपने स्टार्टअप क्रम के भीतर है या नहीं, और काम उस क्रम से अलग किया गया है या नहीं। अधिकांश स्क्रिप्टें तीसरी शर्त पर विफल होती हैं। नींद जोड़ना जीवनचक्र की समस्या को समय की समस्या मानता है, और यह ठीक उतनी बार काम करता है जितना भ्रमित करने के लिए पर्याप्त है।

पहले घटना तय करें, फिर काम टालने का तंत्र, फिर वह जगह जहाँ टाला गया काम चलता है। ये तीन निर्णय स्वतंत्र हैं, और इन्हें मिलाना ही दो पंक्तियों के हुक को पूरी दोपहर बनाने का तरीका है।

हुक ऐसी टनल का इंतज़ार क्यों करता है जो उसका इंतज़ार कर रही है

OpenVPN अपने हुकों को समकालिक रूप से बुलाता है, उसी प्रक्रिया के भीतर जो पैकेट को आगे बढ़ाती है। tun या tap उपकरण होने के बाद पर कोई रूट जोड़े जाने से पहले up चलता है, और रूट के बाद route-up चलता है; इन दोनों क्षणों में से कोई भी यह वादा नहीं करता कि सामने वाला पक्ष उत्तर देगा। जब तक किसी भी हुक की स्क्रिप्ट चल रही है, डेमॉन आगे नहीं भेज रहा होता, इसलिए जो आदेश ट्रैफ़िक के टनल से गुज़रने की अपेक्षा करता है वह ऐसी टनल का इंतज़ार करता है जो उस आदेश का इंतज़ार कर रही है। यही चक्रीय प्रतीक्षा कारण है कि हाथ से चलाना सफल होता है और हुक का समय समाप्त हो जाता है।

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

सुविधा से नहीं, घटना से हुक चुनें

केवल उपकरण चाहने वाले काम से up जोड़ें, रूट चाहने वाले काम से route-up, और client-connect तथा client-disconnect रखें सर्वर पक्ष पर प्रति-क्लाइंट कार्यों के लिए। डिस्कनेक्ट पर सफ़ाई को दो बार चलना सहना चाहिए, क्योंकि स्थायी इंटरफ़ेस पर पुनः कनेक्ट पूर्ण रीस्टार्ट जैसा ही क्रम नहीं अपनाता। सर्वर पर, डेमॉन के शुरू होने पर नहीं बल्कि क्लाइंट के प्रमाणित होने पर client-connect चलता है, जिसे वहाँ तर्क ले जाने से पहले जाँचना उचित है। यदि काम एकल कनेक्शन के बजाय सेवा के जीवनचक्र का है, तो systemd इकाई किसी भी हुक से बेहतर ठिकाना है।

हुक आदेशों को डेमॉन सीधे चलाता है, बीच में कोई शेल नहीं, इसलिए up पंक्ति में ifconfig_remote शाब्दिक पाठ के रूप में आता है। आदेश को स्पष्ट शेल में लपेटें, या तर्क को ऐसी स्क्रिप्ट में रखें जो परिवेश पढ़ती है। ipchange एक निर्देश है जो अपने स्वयं के तर्क जोड़ता है: यह आदेश को पता और पोर्ट सौंपता है, इसलिए बिना किसी के लिए लिखी स्क्रिप्ट दो अप्रत्याशित तर्क देखती है।

काम अलग करने के तीन तरीके

पहला विकल्प हुक के भीतर से सहायक को पृष्ठभूमि में भेजना है: उसे setsid या systemd-run --scope से शुरू करें, विरासत में मिले डिस्क्रिप्टर बंद करें, और तुरंत शून्य के साथ बाहर निकलें। दूसरा यह है कि हुक एक छोटी स्थिति फ़ाइल लिखे और systemd टाइमर या पथ इकाई उस पर कार्य करे, जो हुक को तुच्छ रखता है और पुनः प्रयास नीति को वहाँ रखता है जहाँ लॉग हैं। तीसरा यह है कि हुक को पूरी तरह छोड़ दें और काम को VPN सेवा के बाद क्रमित इकाई में ले जाएँ, जो सही उत्तर है जब काम बिल्कुल भी प्रति-कनेक्शन न हो। तीनों एक नियम साझा करते हैं: हुक को टनल की ज़रूरत पड़ने से पहले लौटना होगा।

जो भी चुनें, सहायक को इडेम्पोटेंट और अवलोकनीय बनाएँ। दो अतिव्यापी आह्वानों को वही अपरिवर्तनीय क्रिया दो बार नहीं चलानी चाहिए, और विफल सहायक को कुछ ऐसा छोड़ना चाहिए जिसे मनुष्य पढ़ सके।

सैंडबॉक्स विफलताओं को जीवनचक्र विफलताओं से अलग करें

जब स्क्रिप्ट root प्रॉम्प्ट से चलती है और सेवा के रूप में विफल होती है, तो कारण आमतौर पर नेटवर्क नहीं बल्कि सैंडबॉक्स होता है। प्रतिबंधक ProtectHome, केवल-पढ़ने वाला ProtectSystem, या ऐसी कार्य निर्देशिका जो मौजूद नहीं है स्क्रिप्ट या उसके डेटा को अगम्य छोड़ सकते हैं, और SELinux होस्ट पर फ़ाइल को ऐसा संदर्भ भी चाहिए जो निष्पादन की अनुमति दे। systemctl cat openvpn-server@server से इकाई और journalctl -u openvpn-server@server -n 80 से जर्नल पढ़ें, फिर कनेक्शन टाइमआउट के बजाय अनुमति या संदर्भ त्रुटि खोजें। सैंडबॉक्स अक्षम करना पहला नहीं, अंतिम कदम होना चाहिए।

जीवनचक्र विफलता अलग दिखती है: हुक शुरू होता है, सहायक चलता है, और सॉकेट बस अभी वहाँ नहीं है। हुक से ही टाइमस्टैम्प वाली पंक्ति लिखें, डिस्कनेक्ट करके फिर जुड़ें, और घटनाओं को क्रम में पढ़ें। जब सहायक को सचमुच टनल चाहिए, तो उसे निश्चित अवधि सोने के बजाय तैयारी पूछने दें।

तीन फ़ील्ड अगली रिपोर्ट को उपयोगी बनाते हैं: कौन-सा हुक चला, किस खाते का उपयोग किया, और कहाँ रुका। इनके बिना हर बाद की जाँच शुरू से होती है।