इंटरॅक्टिव्ह लॉगिननंतर 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 फाइल तुम्ही पडताळलेल्या प्रक्रियेकडे निर्देश करते, सुपरवायझरचा प्रश्न एका बाजूने निकाली निघाला, आणि कुकीकडे साध्या मजकूर फाइल नसलेली साठवण योजना आहे. चारही खऱ्या असतील तर टर्मिनलपासून दूर जाणे सुरक्षित आहे आणि टनेल चालू राहते.

त्यातील एक अयशस्वी झाल्यास, इतरांना स्पर्श करण्यापूर्वी तो मुद्दा दुरुस्त करा, कारण उर्वरित तपासण्या त्याची भरपाई करू शकत नाहीत. पहिल्या फेरीची समोरची प्रतही ठेवा: पुढच्या वेळी टनेल इशाऱ्याशिवाय पडल्यास, तीच आधाररेषा गेटवे बाजूचा बदल क्लायंट बाजूच्या बदलापासून वेगळा करते.