क्लाइंट हुक या सर्वर हुक? OpenVPN स्क्रिप्ट कहाँ चलती है

काम साफ़ है: जब लैपटॉप कनेक्ट होता है, तो लैपटॉप पर कुछ बदलना चाहिए। जिस कॉन्फ़िगरेशन को संपादित किया जा रहा है वह सर्वर का है, और यहीं यह मान्यता टूटती है। सर्वर फ़ाइल में दिया गया पाथ उसी सर्वर पर की फ़ाइल को दर्शाता है, और कितना भी push करें, यह नहीं बदलता कि कौन-सी प्रक्रिया उसे चलाती है। दोनों हुक में से चुनना मुख्य रूप से यह तय करना है कि काम किस मशीन का है, और उससे आने वाली सीमाओं को स्वीकार करना है।

दो मशीनें, पहले उत्तर देने के लिए दो सवाल

पूछें कि स्थिति परिवर्तन कहाँ होना चाहिए, फिर पूछें कि कौन-सी घटना उससे मेल खाती है। अगर परिवर्तन प्रति-उपयोगकर्ता प्राधिकरण या प्रति-क्लाइंट कॉन्फ़िगरेशन निर्णय है, तो वह वहीं जाता है जहाँ उपयोगकर्ता निर्देशिका ज्ञात है: सर्वर पर। अगर परिवर्तन कोई रूट है, resolver सेटिंग या किसी एंडपॉइंट पर स्थानीय सहायक, तो वह एंडपॉइंट पर ही जाता है, और केवल एंडपॉइंट ही उसे कर सकता है।

इन दोनों सवालों का उल्टे क्रम में उत्तर देना ही वह रास्ता है जिससे लोग Windows लैपटॉप पर बैच फ़ाइल push करने की कोशिश करने पहुँचते हैं। सर्वर जानता है कि कौन कनेक्ट हुआ; लैपटॉप जानता है कि उसका अपना नेटवर्क स्टैक कैसा दिखता है। किसी के पास दूसरे की जानकारी नहीं है, और यह कोशिश आमतौर पर स्पष्ट त्रुटि के बजाय चुपचाप विफल हो जाती है।

दोनों से पहले एक तीसरा सवाल पूछना उचित है: क्या प्लेटफ़ॉर्म वह हुक देता भी है जो आप चाहते हैं? जो उपकरण अपना कॉन्फ़िगरेशन खुद बनाता है, वह वही घटना नाम न दे सकता है, और .ovpn फ़ाइल आयात करने वाला डेस्कटॉप क्लाइंट ज़रूरी नहीं वही क्लाइंट हो जिसके लिए फ़ाइल लिखी गई थी। प्लेटफ़ॉर्म की पहले पुष्टि करना आपको ऐसे हुक के इर्द-गिर्द डिज़ाइन करने से बचाता है जो वहाँ है ही नहीं। यह यह भी बताता है कि आपके सामने की मशीन पर कौन-सा दस्तावेज़ वास्तव में लागू होता है।

सर्वर-पक्षीय विकल्प: प्रति कनेक्शन एक घटना

client-connect स्क्रिप्ट सर्वर की प्रक्रिया संदर्भ में तब चलती है जब कोई प्रमाणित क्लाइंट कनेक्ट होता है, और उसे common name तथा आवंटित पता जैसे प्रलेखित कनेक्शन विवरण मिलते हैं। प्रति-क्लाइंट कॉन्फ़िगरेशन अंश लिखने, नीति निर्णय लागू करने या सर्वर के स्वामित्व वाली स्थिति दर्ज करने के लिए यह सही जगह है।

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

वेब इंटरफ़ेस वाले उपकरण पर, जनरेट की गई डेमन फ़ाइलें संपादित करने के बजाय समर्थित एक्सटेंशन तंत्र का उपयोग करें। जनरेट की गई फ़ाइलें अगली बार सहेजने पर फिर से लिखी जाती हैं, और यह पुनर्लेखन आपका बदलाव सबसे बुरे समय पर चुपचाप हटा देता है। एक्सटेंशन टेक्स्ट की एक प्रति उपकरण के बाहर रखें ताकि फ़र्मवेयर अपडेट भी मंशा न खो दे।

क्लाइंट-पक्षीय विकल्प: वह काम जो स्थानीय रूप से ही चलना चाहिए

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

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

नामकरण भी मायने रखता है। up हुक डिवाइस बनने से मेल खाता है और route-up रूट इंस्टॉल होने से, लेकिन जिस काम के लिए निजी नेटवर्क तक पहुँच होना ज़रूरी है उसे पहुँच-क्षमता जाँचनी चाहिए, यह मानने के बजाय कि डिवाइस बन जाने का मतलब है कि हर रूट, resolver प्रविष्टि और एप्लिकेशन तैयार है।

चलाने योग्य कोड push करना विकल्पों में क्यों नहीं है

push किए गए विकल्प जानबूझकर सीमित हैं, और स्क्रिप्ट चलाने वाले विकल्प उन श्रेणियों में हैं जिन्हें सर्वर को नीचे भेजने की अनुमति नहीं है। यह सीमा इसलिए है क्योंकि विकल्प होता तो कोई समझौता-ग्रस्त या गलत कॉन्फ़िगर सर्वर हर उस क्लाइंट पर मनमाने कमांड चला सकता जो कभी कनेक्ट होता है।

स्थानीय रूप से स्क्रिप्ट चलाना सक्षम करना इसे नहीं बदलता। आपकी script-security सेटिंग उन स्थानीय स्क्रिप्ट को अनुमति देती है जिन्हें आपने चुना; यह सर्वर को नई स्क्रिप्ट देने का अधिकार नहीं देती।

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

किसी भी हुक पर भरोसा करने से पहले क्या जाँचें

हर हुक के लिए चार चीज़ें लिखें: मशीन, घटना का नाम, वह खाता जिसके अंतर्गत वह चलता है, और वह स्थिति परिवर्तन जो उसे उत्पन्न करना है। फिर कनेक्शन, पुनःकनेक्शन और सफ़ाई का रास्ता जाँचें, क्योंकि पुनःकनेक्शन पर स्थिति लीक करने वाला हुक कभी न चले हुक से भी बुरा है।

जो खाता वास्तव में इसे चलाएगा उसी के अंतर्गत, उसी क्षण जाँचें जब यह वास्तव में चलेगा। openvpn(8) मैनुअल दोनों हुक परिवारों और push सीमाओं का दस्तावेज़ीकरण करता है; आप जिस प्लेटफ़ॉर्म पर तैनात कर रहे हैं वह दस्तावेज़ीकरण करता है कि क्या वह उन्हें बिल्कुल भी उपलब्ध कराता है। इंटरैक्टिव एडमिनिस्ट्रेटर टर्मिनल में सफल होने वाली स्क्रिप्ट एक अनुमान है, सत्यापन नहीं।