OpenConnect लगइन गलत पृष्ठमा पुग्छ? पहिले बाटो जाँच्नुहोस्

तपाईं अनबोर्डिङ मेलबाट ठेगाना टाँस्नुहुन्छ, क्लाइन्ट गेटवेसम्म पुग्छ, र देखिने लगइन फारम अपरेटरले वर्णन गरेको साझेदार पोर्टल नभई सामान्य पोर्टल हो। केही पनि त्रुटि देखाउँदैन, र यही कुराले अन्योल बनाउँछ: टनेल उठ्न पनि सक्छ, तर गलत प्रवेश बिन्दुको पछाडि। त्यो URL को बाटोले काम गरिरहेको थियो, र यसलाई जसले पनि बदल्यो, त्यसले त्यो काम छोड्यो।

टिकटमा एउटै स्ट्रिङका रूपमा आउने दुई कुरा अलग गर्नुहोस्: सेवासम्म पुग्ने ठेगाना, र प्रमाणीकरण कहाँबाट सुरु हुन्छ भन्ने निर्धारण गर्ने इनपुट। पहिलो सुधारेर दोस्रो बेवास्ता गर्नु नै सही होस्टनामले पनि गलत लगइन दिने तरिका हो।

फारम देख्नु अघि क्लाइन्टले के पठाउँछ

https://vpn.example.net/partners जस्तो ठेगानासँग क्लाइन्टको पहिलो काम नाङ्गो होस्टमा होइन, त्यो बाटोमा HTTPS अनुरोध हो। फर्केर आउने कुरा सामान्यतया साइन-इन एन्डपोइन्टमा रिडाइरेक्ट, वा फारम आफैं हुन्छ। केवल vpn.example.net पाएको क्लाइन्ट जुनसुकै पूर्वनिर्धारित ल्यान्डिङ पृष्ठबाट सुरु गर्छ, र त्यो अर्को पोर्टल, अर्को समूह सूची, वा पूर्ण रूपमा फरक प्रोटोकल अपेक्षा गर्ने पृष्ठ हुन सक्छ। फरक कुनै पनि प्रमाणपत्र टाइप हुनुभन्दा धेरै अघि प्रतिक्रिया हेडरहरूमा देखिन्छ।

त्यसैले काम गर्ने ब्राउजर ट्याब र असफल हुने क्लाइन्ट प्रोफाइलले एउटै गेटवेको नाम लिए पनि फरक पर्न सक्छन्। ब्राउजरले बाटो पछ्यायो; प्रोफाइलसँग त्यो कहिल्यै थिएन।

अदलबदल गर्न मिल्ने जस्तो देखिने र नमिल्ने दुई इनपुट

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

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

अपरेटरसँग प्रत्येक मान आफ्नै लाइनमा माग्नुहोस्: प्रवेश बाटो, फारम छनोट, र दुवै आवश्यक छन् कि छैनन्। लेबल उस्तै सुनिन्छ भनेर एउटाबाट अर्को अनुमान नगर्नुहोस्।

बाटो छोट्याउँदा नतिजा किन बदलिन्छ

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

होस्टनामलाई IP ठेगानाले बदल्नु यसैसँग प्रायः यात्रा गर्ने छुट्टै गल्ती हो। नाममा आधारित सेवा छनोट र प्रमाणपत्र प्रमाणीकरण दुवै नाममा निर्भर छन्, त्यसैले सङ्ख्यात्मक ठेगानाले बाटो-ढाँचाको समस्यालाई TLS त्रुटिमा बदल्न सक्छ।

ब्राउजर ठेगानाले बाटोभन्दा बढी पनि बोक्छन्। सत्र पहिचानकर्ता, रिडाइरेक्ट लक्ष्य, भाषा उपसर्ग र अस्थायी साइन-इन प्यारामिटर सबै ठेगाना पट्टीमा देखिन्छन्, र यीमध्ये कुनै पनि सुरक्षित क्लाइन्ट प्रोफाइलमा पर्नुहुँदैन।

अरू केही सम्पादन गर्नु अघि प्रवेश बिन्दु पुष्टि गर्नुहोस्

तपाईंलाई दिइएको बाटोका हेडर पढ्नुहोस्। curl -sS -o /dev/null -D - https://vpn.example.net/partners जस्तो अनुरोधले रिडाइरेक्ट नपछ्याई स्थिति लाइन र कुनै पनि Location हेडर छाप्छ। नामित साइन-इन एन्डपोइन्टतर्फ देखाउने 302 ले बाटो अवस्थित छ भनी पुष्टि गर्छ र कहाँ जान्छ देखाउँछ; 404 भनेको अपरेटरको ठेगाना पुरानो भयो भन्ने हो।

त्यसपछि त्यही प्रवेश बिन्दु स्वीकृत क्लाइन्टमा पुनः उत्पादन गर्नुहोस्, उदाहरणका लागि openconnect --usergroup=partners vpn.example.net, र कुन फारम देखिन्छ हेर्नुहोस्। फारम सही भए पनि टनेल असफल भयो भने, बाटो कहिल्यै समस्या थिएन र अर्को ठाउँ नीति वा राउटिङ हो।

टिकटमा होस्टनाम, पोर्ट, प्रोटोकल, प्रवेश बाटो र फारम छनोटलाई पाँच अलग फिल्डका रूपमा लेख्नुहोस्। त्यही सूचीले अर्को इन्जिनियरलाई पुग्न नसकिने सर्भर, TLS अस्वीकृति, अस्वीकृत छनोट र आवश्यक मार्ग बिना उठेको टनेलबीच फरक गर्न दिन्छ।