इंटरैक्टिव लॉगिन के बाद OpenConnect को बैकग्राउंड में कैसे चलाएँ

आप MFA प्रॉम्प्ट पूरा करते हैं, टनल ऊपर आता है, और टर्मिनल बंद करने से कनेक्शन भी चला जाता है। यह पर्यवेक्षण की समस्या है, प्रमाणीकरण की नहीं, और OpenConnect में इसे हल करने वाला स्विच पहले से है। समाधान यह है कि स्टार्टअप पूरा होने के बाद क्लाइंट को बैकग्राउंड में फोर्क होने दें, जब इंटरैक्टिव हिस्सा सचमुच खत्म हो चुका हो। नीचे जाँचों का क्रम है: क्रम से चलें और पहली ऐसी जाँच पर रुकें जो आपके गेटवे पर लागू न हो।

पुष्टि करें कि लॉगिन पर गेटवे क्या माँगता है

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

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

पहला सत्र फोरग्राउंड में चलाएँ और आउटपुट पढ़ें

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

फिर वही कॉल बैकग्राउंड मोड और PID फ़ाइल जोड़कर दोहराएँ, जैसे openconnect --background --pid-file /run/openconnect.pid vpn.example.net, और आपके गेटवे को ज़रूरी प्रोटोकॉल व प्रमाणीकरण विकल्प उसी पंक्ति में रखें। OpenConnect मैनुअल इस विकल्प को स्टार्टअप पूरा होने के बाद बैकग्राउंड में जारी रहना बताता है, और इसीलिए इंटरैक्टिव चरण पहले खत्म होना चाहिए।

चल रही प्रक्रिया को खोजने योग्य और रोकने योग्य बनाएँ

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

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

बैकग्राउंड मोड को सुपरवाइज़र के नीचे न रखें

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

--background उन सत्रों के लिए रखें जो कोई व्यक्ति शुरू करके चला जाता है। अगर आवश्यकता ऐसी टनल है जो किसी के लॉगिन से पहले मौजूद हो, तो छूटा हिस्सा स्वीकृत गैर-इंटरैक्टिव पहचान और उसे नवीनीकृत करने की योजना है, और कोई कमांड-लाइन फ़्लैग इनमें से कुछ नहीं देता। बूट स्क्रिप्ट में फ़्लैग जोड़ने से ऐसी टनल बनती है जो पहले समाप्त क्रेडेंशियल पर चुपचाप विफल हो जाती है।

सत्र कुकी को क्रेडेंशियल मानें

OpenConnect --authenticate के ज़रिए अलग प्रमाणीकरण चरण का दस्तावेज़ीकरण करता है, और परिणामी सामग्री --cookie-on-stdin से लौटाई जा सकती है। यह जोड़ी एकीकरण कार्य के लिए है, और जो पैदा होता है वह उतना ही संवेदनशील है जितना उसे बनाने वाला पासवर्ड।

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

टर्मिनल बंद करने से पहले सूची पूरी करें

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

अगर उनमें से एक विफल हो, तो बाकियों को छूने से पहले उसी मद को ठीक करें, क्योंकि बाकी जाँचें उसकी भरपाई नहीं कर सकतीं। पहले रन की फोरग्राउंड ट्रांसक्रिप्ट भी रखें: अगली बार जब टनल बिना चेतावनी गिरे, तो वही आधार-रेखा गेटवे पक्ष के बदलाव को क्लाइंट पक्ष के बदलाव से अलग करती है।