Juniper वा Pulse गेटवे: कुन OpenConnect प्रोटोकल प्रयोग गर्ने

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 समूह वा अवरुद्ध अनुपालन जाँचबाट छुट्याउँछ। विस्तृत आउटपुट पनि त्यही कारणले राख्न योग्य छ, किनकि यसले लक्षण मात्र होइन, असफल अनुरोध देखाउँछ।

सफल भएपछि चल्ने कमाण्ड वा प्रोफाइल गेटवेको नामनजिक राख्नुहोस्। अन्यथा अर्को जोडिने व्यक्तिले त्यही ब्रान्ड-विरुद्ध-प्रोटोकल अनुमान दोहोर्याउनेछ।