आप ऑनबोर्डिंग मेल से पता चिपकाते हैं, क्लाइंट गेटवे तक पहुँचता है, और जो लॉगिन फ़ॉर्म दिखता है वह सामान्य पोर्टल है, ऑपरेटर द्वारा बताया गया साझेदार पोर्टल नहीं। कोई त्रुटि नहीं दिखती, और यही भ्रम पैदा करता है: टनल तो ऊपर आ भी सकती है, बस गलत प्रवेश-बिंदु के पीछे। उस 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 अस्वीकृति, अस्वीकृत चयन और आवश्यक मार्गों के बिना ऊपर आई टनल में अंतर करने देती है।

संबंधित लेख