OpenVPN पासवर्ड टर्मिनल से पढ़ता है, stdin से नहीं
OpenVPN असल में पासवर्ड कहाँ पढ़ता है, stdin पर रखी फ़ाइल क्यों विफल होती है, और Linux तथा macOS पर स्क्रिप्टेड साइन-इन के तीन समर्थित रास्ते।
OpenVPN नियंत्रक टर्मिनल पर उपयोगकर्ता नाम और पासवर्ड माँगता है, और मानक इनपुट की ओर मोड़ी गई फ़ाइल वह टर्मिनल नहीं है। यही एक ब्योरा उस स्क्रिप्ट को समझाता है जो पासवर्ड पाइप में होते हुए भी अटक जाती है। संकेत क्लाइंट बनाता है और पढ़ाई टर्मिनल यंत्र से होती है, इसलिए stdin मोड़ने से कुछ नहीं बदलता। क्लाइंट को उसके प्रलेखित इनपुट रास्तों में से किसी एक से भरें और वही स्क्रिप्ट पहले प्रयास में जुड़ जाएगी।
तीन रास्ते लगभग हर स्थिति को ढक लेते हैं, और हर एक अपने ढंग से विफल होता है। क्लाइंट जो संकेत वास्तव में दिखाता है उसके अनुसार चुनें, उस विकल्प के अनुसार नहीं जिसे स्क्रिप्ट करना सबसे आसान है।
संकेत stdin से नहीं आता
जब OpenVPN को क्रेडेंशियल चाहिए होते हैं तो वह नियंत्रक टर्मिनल खोलता है और वहीं से पढ़ता है। इसीलिए इंटरैक्टिव परीक्षण ठीक दिखता है, जबकि cron या unit फ़ाइल के अधीन वही कमांड निष्क्रिय बैठा रहता है और संकेत ऐसे लॉग में लिखा जाता है जिसे कोई नहीं देखता। कुछ बिल्ड टर्मिनल न होने पर मानक इनपुट पर लौट जाते हैं, और यह असंगति कठोर विफलता से भी बुरी है, क्योंकि यह तैनाती तक समस्या छिपाए रखती है।
कोई भी कोड लिखने से पहले वातावरण जाँचें: क्लाइंट को उसी उपयोगकर्ता और उसी stdin के साथ चलाएँ जो शेड्यूलर या सेवा प्रबंधक चलाएगा। यदि संकेत कभी लॉग में न आए और प्रक्रिया आगे न बढ़े, तो कुछ ऐसे टर्मिनल का इंतज़ार कर रहा है जो मौजूद नहीं है।
पहला रास्ता: दो पंक्तियों की क्रेडेंशियल फ़ाइल
प्रमाणीकरण विकल्प एक पथ लेता है, और फ़ाइल में ठीक दो पंक्तियाँ होती हैं, पहले उपयोगकर्ता नाम फिर पासवर्ड, और कुछ नहीं। डिफ़ॉल्ट फ़ाइल नाम पर भरोसा करने के बजाय पथ स्पष्ट रूप से दें, क्योंकि कार्य निर्देशिका में पड़ी भूली हुई क्रेडेंशियल फ़ाइल ही गलत खाते के उपयोग में आने का रास्ता है। मोड 0600 पर सेट करें और स्वामित्व उस खाते को दें जो क्लाइंट चलाता है।
क्लाइंट वह फ़ाइल शुरू होने पर एक बार पढ़ता है, इसलिए पासवर्ड बदलने का अर्थ प्रक्रिया पुनः आरंभ करना है। सामान्यतः यही वह व्यवहार है जो आप चाहते हैं, और यह बदलने की प्रक्रिया के बगल में रनबुक में जाना चाहिए।
दूसरा रास्ता: कुंजी के पासफ़्रेज़ के लिए askpass
पासफ़्रेज़ से सुरक्षित निजी कुंजी दूसरा, अलग संकेत उठाती है, और उसका अपना फ़ाइल-आधारित उत्तर है: askpass विकल्प पासफ़्रेज़ को किसी फ़ाइल की पहली पंक्ति से पढ़ता है। SSH-आधारित सुरंगों के लिए समकक्ष वह askpass प्रोग्राम है जिसे क्लाइंट चलाता है, और जिसका मानक आउटपुट रहस्य बन जाता है।
दोनों में से कोई रूप रहस्य को तर्क-सूची में नहीं रखता, और दोनों उसे फ़ाइल के रूप में या उसे छापने वाले निष्पाद्य के रूप में रहने देते हैं। सुरक्षा फ़ाइल अनुमतियाँ और प्रक्रिया स्वामित्व है, गोपनीयता नहीं। कोड में लिखी स्ट्रिंग को दोहराने वाला सहायक अतिरिक्त चरणों वाला रहस्य है।
तीसरा रास्ता: पोर्टल क्लाइंट की अपनी CLI
उद्यम क्लाइंट सामान्यतः कमांड-लाइन प्रवेश बिंदु देते हैं जो बिना किसी विंडो के नामित पोर्टल से जुड़ता है, और यही समर्थित रास्ता है। Linux पर GlobalProtect क्लाइंट अपनी CLI के ज़रिए कनेक्ट और प्रमाणपत्र आयात क्रियाएँ देता है, और प्रमाणपत्र प्रमाणीकरण वाले पोर्टलों को स्वचालित कनेक्ट के काम करने से पहले आयात चरण चाहिए। संश्लेषित कुंजी-दबावों की तुलना में इसे प्राथमिकता दें: आपको असली एक्ज़िट स्थिति मिलती है, विंडो फ़ोकस पर निर्भरता नहीं होती, और यह लॉक स्क्रीन पर भी टिकता है।
यदि पहले कनेक्शन को अभी भी प्रमाणपत्र स्वीकार करने के लिए किसी मनुष्य की ज़रूरत हो, तो स्वचालन पूरा नहीं हुआ। सेटअप के दौरान आयात करें और उसे पूर्वापेक्षा के रूप में दर्ज करें।
जब प्रवाह को छद्म-टर्मिनल चाहिए
जो क्रम पहले पासवर्ड और फिर एक-बार वाला कोड माँगता है, उसके पास पढ़ने के लिए कोई एक फ़ाइल नहीं है। Expect जैसा टर्मिनल ड्राइवर सही औज़ार है, क्योंकि वह बारी-बारी हर पैटर्न का इंतज़ार करता है, और कुछ भी मिलाने से पहले उसे प्रक्रिया शुरू हो चुकी चाहिए।
दो विफलताएँ हावी हैं। बिना क्लाइंट शुरू किए संकेत का इंतज़ार करती स्क्रिप्ट हमेशा इंतज़ार करती रहती है, और Tcl शेल नहीं है, इसलिए expect ब्लॉक के भीतर लिखा शेल अंकगणित वैसे नहीं आँका जाता जैसे वह पढ़ा जाता है। पैटर्न बनाते समय डीबग फ़्लैग चालू रखें, फिर उसे बंद करें।
जो रहस्य रिसते हैं, और वे कहाँ छिपते हैं
तर्क के रूप में दी गई कोई भी चीज़ प्रक्रिया सूची में दिखती है, इसलिए क्रेडेंशियल फ़ाइल में या किसी सहायक के पीछे रहते हैं, कभी कमांड लाइन पर नहीं। एक-बार वाले कोड डिज़ाइन से खपत होते हैं और हर प्रयास के लिए बनाने पड़ते हैं। विफलता लॉग अक्सर उपयोगकर्ता नाम और कभी-कभी उससे अधिक लिए होते हैं, इसलिए कहीं भेजने से पहले उन्हें संपादित करें, और रहस्य को प्रोफ़ाइल से बाहर रखें, क्योंकि अंदर पासवर्ड वाली कॉन्फ़िग फ़ाइल टिकट और रिपॉज़िटरी में चिपक जाती है। तब खाता बदलने का अर्थ हर प्रति का शिकार करना है, और यही वह लागत है जिससे यह व्यवस्था बचती है।
आपने जो रास्ते चुने उनका अंकेक्षण करें, फिर उन्हें उस unit फ़ाइल या शेड्यूलर से जोड़ें जो वास्तव में क्लाइंट चलाएगा। सुरंग ठीक तब तक जीवित रहती है जब तक वह प्रक्रिया जीवित है।