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

OpenConnect पुराने प्रोटोकॉल को nc और नए को pulse कहता है, और दोनों एक ही बाइनरी में रहते हैं। आप जो फ़्लैग चुनते हैं वह लॉगिन का आदान-प्रदान बदलता है, सफल कनेक्शन के बाद की राउटिंग नहीं।

दो प्रोटोकॉल नाम एक ही उत्पाद इतिहास साझा करते हैं

Juniper का Network Connect और बाद का Pulse Secure क्लाइंट अलग प्रोटोकॉल हैं जिन्हें एक उपकरण परिवार ने समय के साथ पेश किया। OpenConnect ने पहले के लिए nc हैंडलर और दूसरे के लिए pulse हैंडलर विकसित किया। ये अलग कोड पथ और अलग अनुरोध प्रारूप हैं, इसलिए एक में समर्थन होने से दूसरे के बारे में कुछ पता नहीं चलता।

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

कमांड लाइन पर चुनना एक शब्द का बदलाव है: Network Connect के लिए openconnect --protocol=nc vpn.example.com, या Pulse के लिए openconnect --protocol=pulse vpn.example.com। दोनों प्रयास असली कनेक्शन प्रयास हैं जो रूट और DNS फिर से सेट कर सकते हैं, इसलिए इन्हें जानबूझकर चलाएँ। प्रोटोकॉल त्रुटि से बचने के लिए कभी कमांड लाइन पर पासवर्ड न रखें और प्रमाणपत्र जाँच बंद न करें, क्योंकि इससे बेमेल छुपता है, ठीक नहीं होता। अगर देखना हो कि क्लाइंट क्या भेजता है, तो --dump-http-traffic आदान-प्रदान प्रिंट करता है, जो आमतौर पर वह हैंडलर पहचानता है जिसकी गेटवे अपेक्षा करता है।

प्रोटोकॉल को उसके साथ मिलाएँ जो गेटवे पेश करता है

उपकरण केवल उसी प्रोटोकॉल का उत्तर देता है जिसके लिए वह कॉन्फ़िगर है। केवल Pulse वाली सेवा वैध क्रेडेंशियल के साथ भी nc लॉगिन अस्वीकार करती है, और पुरानी Network Connect सेवा के पास जवाब देने के लिए कोई pulse एंडपॉइंट नहीं है। व्यवस्थापक से पूछें कि कौन सा सक्षम है और वे किस क्लाइंट का समर्थन करते हैं। नाम बदला हुआ उपकरण, पुराना विकी पेज और परिचित वेब पोर्टल सभी कमज़ोर सबूत हैं।

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

प्रमाणीकरण प्रोटोकॉल से पहले ही सवाल तय कर सकता है

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

auth समूह का चयन दूसरी आम अड़चन है, क्योंकि कई समूहों वाला गेटवे अपेक्षा करता है कि क्लाइंट एक का नाम ले।

कमांड लाइन पर --authgroup="Employees" वह चयन देता है, और उसे छोड़ने से सत्र डिफ़ॉल्ट समूह में जा सकता है जो खाता अस्वीकार करता है। प्रमाणपत्रों के साथ --certificate क्लाइंट प्रमाणपत्र और कुंजी की ओर इशारा करता है, और गेटवे बाद में भी टोकन माँग सकता है। इसके आसपास कुछ भी स्वचालित करने से पहले पूरा क्रम एक बार विस्तृत आउटपुट के साथ जाँचें।

जब डेस्कटॉप फ़्रंटएंड चयन व्यक्त नहीं कर सकता

ग्राफ़िकल फ़्रंटएंड अपने फ़ीचर सेट लाते हैं, और पुराना प्लगइन उस प्रोटोकॉल से पहले का हो सकता है जो आपको चाहिए। NetworkManager का OpenConnect एकीकरण चयन को अपने कनेक्शन डेटा में रखता है, इसलिए nmcli connection modify "Office VPN" vpn.data "protocol=pulse" वह सेट कर सकता है जो संपादक नहीं दिखाता। यह मानने से पहले कि बदलाव लागू हुआ, जाँचें कि स्थापित प्लगइन संस्करण उस कुंजी का समर्थन करता है।

अगर कोई मेनू केवल PPTP या L2TP देता है, तो एक चुनने से Pulse सेवा उस प्रोटोकॉल में नहीं बदलती। मेनू जो भी सूचीबद्ध करे उस पर जाने के बजाय स्वीकृत एकीकरण स्थापित करें।

जब लॉगिन फिर भी विफल हो तो क्या दर्ज करें

चार चीज़ें दर्ज करें: आपका चुना प्रोटोकॉल, क्लाइंट और प्लगइन के संस्करण, अपेक्षित प्रमाणीकरण प्रवाह, और टाइमआउट के बजाय स्टेटस कोड के साथ लौटी पहली त्रुटि। यह सेट गलत हैंडलर को छूटे प्रमाणपत्र, अस्वीकृत auth समूह या अवरुद्ध अनुपालन जाँच से अलग करता है। विस्तृत आउटपुट इसी कारण रखने योग्य है, क्योंकि यह केवल लक्षण नहीं, विफल अनुरोध दिखाता है।

सफल होने पर चलने वाला कमांड या प्रोफ़ाइल गेटवे के नाम के पास रखें। वरना अगला जुड़ने वाला व्यक्ति वही ब्रांड-बनाम-प्रोटोकॉल अनुमान दोहराएगा।

संबंधित लेख