पोर्टल 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 घेण्यापासून रोखतात।

एक कनेक्शन सुरुवातीपासून शेवटपर्यंत पुन्हा तपासा आणि लागू केलेले धोरण तसेच प्रत्यक्षात आवश्यक संसाधनातील प्रवेश या दोन्हींची पुष्टी करा। प्रमाणीकरण यशस्वी होणे ही त्या तपासणीची सुरुवात आहे, शेवट नाही।