पोर्टल URL चिपकाने पर openfortivpn लॉगिन क्यों विफल होता है

विफलता क्रेडेंशियल की समस्या जैसी दिखती है: openfortivpn पासवर्ड माँगता है, उसे भेजता है, और गेटवे अस्वीकृति या लॉगिन पृष्ठ पर वापस रीडायरेक्ट के साथ उत्तर देता है। फिर उपयोगकर्ता पासवर्ड दोबारा टाइप करते हैं, डोमेन के साथ खाता नाम आज़माते हैं, और अंत में ब्राउज़र का पोर्टल URL होस्ट फ़ील्ड में चिपका देते हैं। यही अंतिम कदम एक छोटी कॉन्फ़िगरेशन गलती को उलझाने वाली गलती बना देता है।

https://vpn.example.com/ext जैसा Fortinet पोर्टल पता एक साथ कई जानकारी के टुकड़े ले जाता है, और उनमें से केवल कुछ ही VPN क्लाइंट के होते हैं।

एंडपॉइंट और realm अलग-अलग इनपुट हैं

openfortivpn host या host:port रूप में एक एंडपॉइंट की अपेक्षा करता है, साथ में एक खाता और, जहाँ परिनियोजन एक का उपयोग करता है, एक realm मान। realm खाते का मूल्यांकन करने से पहले गेटवे को बताता है कि कौन-सी प्रमाणीकरण नीति लागू करनी है। यह अलग फ़ील्ड है, कोई प्रत्यय नहीं जिसे क्लाइंट URL से निकालता है।

जिस परिनियोजन का संचालक पुष्टि करता है कि realm ext है, उसके लिए गैर-गोपनीय आह्वान ऐसा दिखता है: openfortivpn vpn.example.com:443 --username=alice --realm=ext। वही मान कॉन्फ़िगरेशन फ़ाइल में host, port, username और realm प्रविष्टियों के रूप में जाते हैं। पासवर्ड को दोनों रूपों से बाहर रखें और क्लाइंट से पूछने दें, ताकि वह शेल इतिहास या ऐसी फ़ाइल में न पहुँचे जिसे सभी पढ़ सकें। पहला क्लाइंट अभी टनल थामे रहने के दौरान दूसरा प्रयास ऐसे कारण से विफल होगा जिसका realm से कोई संबंध नहीं है।

openfortivpn मैनुअल दोनों विकल्प सूचीबद्ध करता है, इसलिए सहायता को कॉल करने से पहले सटीक वर्तनी जाँचना आसान है। हालाँकि यह नहीं बता सकता कि आपके गेटवे पर कौन-सा realm कॉन्फ़िगर है।

पथ खंड अपने आप realm नहीं होता

पोर्टल URL होस्टनाम के बाद तरह-तरह की चीज़ें जमा करते हैं: लॉगिन एप्लिकेशन, भाषा चयनकर्ता, रीडायरेक्ट लक्ष्य, सत्र पहचानकर्ता। अंतिम पथ खंड काटकर उसे realm कहना इतनी बार काम करता है कि यह खतरनाक हो जाए। संचालक से कॉन्फ़िगर किया गया मान पूछें, या उसे उस प्रोफ़ाइल से पढ़ें जो आपका संगठन वितरित करता है।

realm उपयोगकर्ता नाम पर डोमेन प्रत्यय या गेटवे जिस क्षेत्र में स्थित है, वह भी नहीं है। कुछ परिनियोजन alice चाहते हैं, कुछ alice@corp चाहते हैं, और realm तय करता है कि गेटवे इनमें से किसे स्वीकार करेगा। गलत realm की भरपाई के लिए खाता प्रारूप बदलने पर आमतौर पर दूसरी, कम जानकारी देने वाली अस्वीकृति मिलती है।

होस्ट बदलकर realm त्रुटि ठीक न करें

होस्टनाम की जगह IP पता लगाना एक परत हटाने जैसा लगता है, और यह ठीक करने से ज़्यादा तोड़ता है। TLS नाम सत्यापन प्रमाणपत्र की तुलना उस नाम से करता है जो क्लाइंट ने उपयोग किया, और IP पता प्रमाणपत्र के वैकल्पिक विषय नामों में शायद ही आता है। सर्वर नाम संकेतक पते के साथ बदलता है, इसलिए एक पते पर कई पोर्टल होस्ट करने वाला गेटवे गलत पोर्टल के साथ उत्तर दे सकता है। प्रमाणीकरण पैरामीटर सुधारते समय होस्टनाम और विश्वास कॉन्फ़िगरेशन अक्षुण्ण रखें।

यदि आपके वातावरण में प्रमाणपत्र भरोसेमंद नहीं है, तो विश्वास भंडार ठीक करें या अपेक्षित प्रमाणपत्र को जानबूझकर पिन करें। realm त्रुटि से बचने के लिए सत्यापन बंद करना लॉगिन समस्या के बदले मौन अवरोधन का जोखिम लेता है।

अस्वीकृत लॉगिन को विफल टनल से अलग करें

प्रमाणीकरण विफलताएँ और टनल विफलताएँ अलग-अलग क्षणों में आती हैं, और संदेश अलग होते हैं। नाम विश्लेषण त्रुटि किसी भी TLS हैंडशेक से पहले होती है। TLS अस्वीकृति क्रेडेंशियल भेजे जाने से पहले होती है। realm या खाता अस्वीकृति पोर्टल से HTTP स्तर के उत्तर के रूप में लौटती है। उन चरणों के बाद ही PPP वार्ता शुरू होती है, और तभी रूटिंग और DNS समस्याएँ दिखाई देती हैं।

सही realm गुम रूट नहीं बनाता, और असमर्थित साइन-इन विधि को काम नहीं कराता। यदि पोर्टल ब्राउज़र आधारित प्रवाह पर ज़ोर देता है, तो पासवर्ड विनिमय दोहराकर सत्र मेल खाने की आशा करने के बजाय उस प्रवाह के लिए क्लाइंट का समर्थित मार्ग उपयोग करें।

मानों को वहीं रखें जहाँ अगला प्रारंभ उन्हें पाएगा

कनेक्शन सफल होने पर, शेल उपनाम के बजाय गेटवे, पोर्ट, खाता और realm को प्रबंधित प्रोफ़ाइल में लिखें। रिपॉज़िटरी या कॉन्फ़िगरेशन प्रबंधन प्रणाली में रखी प्रोफ़ाइल अगले प्रारंभ को चुपचाप किसी अन्य प्रोफ़ाइल का realm उठाने से रोकती हैं।

एक कनेक्शन को शुरू से अंत तक फिर से परखें और लागू की गई नीति तथा वास्तव में आवश्यक संसाधन तक पहुँच—दोनों की पुष्टि करें। प्रमाणीकरण का सफल होना उस जाँच की शुरुआत है, अंत नहीं।