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 नकार, नाकारलेली निवड आणि आवश्यक मार्गांशिवाय उभे राहिलेले टनेल यात फरक करू देते।