MSCHAPv2 हा VPN प्रोटोकॉल नाही: आधी बोगद्याबद्दल विचारा
पासवर्ड आणि MSCHAPv2 हा शब्द मिळून कनेक्शन होत नाही। कोणता बोगदा ही देवाणघेवाण वाहतो ते विचारा, मग क्लायंट प्रोफाइल त्याला जुळवा।
वापरकर्तानावे आणि पासवर्ड एका वाहकाच्या आत प्रवास करतात, आणि MSCHAPv2 फक्त प्रवास करणाऱ्या पद्धतीचे नाव सांगते। क्लायंट प्रोफाइल निवडण्यापूर्वी कोणता बोगदा तो वाहतो ते विचारा, कारण तीच खाते मालिका कोडची एकही ओळ न सामायिक करणाऱ्या रचनांमध्येही दिसते। तुम्हाला दिलेले प्रत्येक प्रोफाइल दोन्ही निर्णय एन्कोड करते, अगदी सूचना पत्रक त्यातले फक्त एकच छापत असले तरी। खालील क्रम म्हणजे ऑपरेटर अंदाज न लावता उत्तर देऊ शकतो ते आणि तुम्ही पॅकेट न पकडता तपासू शकता ते।
प्रमाणीकरण बोगद्याच्या आत चालते
VPN एकासारखे वाटणारे दोन निर्णय घेते: दोन्ही बाजू संरक्षित चॅनेल कसे बनवतात, आणि व्यक्ती त्याच्या आत आपली ओळख कशी सिद्ध करते। दुसरे सूचना पत्रकावर छापले जाते कारण तेच माणूस टाइप करतो। पहिले ठरवते की कोणतेही क्लायंट अजिबात चालेल की नाही, आणि लोक तेच वगळतात। ऑपरेटरला आधी वाहकाचे आणि नंतर पद्धतीचे नाव सांगायला सांगा, त्याच क्रमाने। दोन कनेक्शन्स एकच खाते नाव आणि एकच पासवर्ड मागू शकतात, पण लॉगिन बॉक्सखाली कोणतीही अंमलबजावणी सामायिक करत नाहीत।
म्हणूनच सहकाऱ्याच्या चालणाऱ्या फोनवरून कॉपी केलेल्या सेटिंग्ज सर्व्हर दोन्ही क्रेडेन्शियल स्वीकारत असूनही तुमच्या फोनवर अपयशी ठरू शकतात। फरक कधीच क्रेडेन्शियल नव्हता; त्याभोवतीचे प्रोफाइल होते। दोन्ही बाजू बरोबर आहेत आणि काहीही जोडले जात नाही सहसा हाच गोंधळ असतो, आणि वाहकाचे नाव येताच तो सुटतो।
तीच पद्धत दिसणारी तीन ठिकाणे
PPP मध्ये प्रमाणीकरणाची पायरी दुवा असेपर्यंत थांबते, आणि RFC 2759 MS-CHAPv2 ला तीच पायरी म्हणून परिभाषित करते, म्हणूनच ही पद्धत L2TP आणि जुन्या PPTP तैनातींमध्ये दिसते। बोगदा आधी संपतो आणि PPP वाटाघाटी त्याच्या आत होते, त्यामुळे अपयशी PPP टप्पा सर्व्हर लॉगमध्ये बोगदा प्रस्थापित असल्यासारखा ठेवू शकतो। क्रेडेन्शियल नाकारली गेली असा निष्कर्ष काढण्यापूर्वी ते दोन टप्पे वेगळे वाचा। त्यामुळे L2TP साठी संरचित क्लायंट पूर्णपणे बरोबर असू शकतो आणि तरीही फक्त IKEv2 बोलणाऱ्या गेटवेसाठी चुकीचा क्लायंट ठरू शकतो।
IKEv2 त्याऐवजी EAP-MSCHAPv2 की एक्स्चेंजच्या आत ठेवते, त्यामुळे तेच क्रेडेन्शियल वेगळ्या क्षणी अपयशी होते आणि सत्र त्रुटीऐवजी प्रमाणीकरण त्रुटी म्हणून पुढे येते। Android चे प्लॅटफॉर्म IKEv2 प्रोफाइल हे रोजचे उदाहरण आहे, आणि ते PPP पर्यायांऐवजी सर्व्हर प्रमाणपत्र किंवा ओळखकर्ता मागते। खाते नाव दोन्ही रचनांमध्ये सारखेच आहे, त्यामुळे तुमच्याकडे कोणते आहे ते सांगू शकत नाही। हे फक्त ऑपरेटरच्या समर्थित प्रोटोकॉलच्या यादीवर ठरते।
TLS आधारित VPN तिसरी रचना जोडते, स्वतःच्या वापरकर्तानाव आणि पासवर्ड फील्डसह आणि देवाणघेवाणीत कुठेही MS-CHAPv2 न घेता। म्हणून पासवर्ड बॉक्स दिसणे हे त्यामागील प्रोटोकॉलचा पुरावा नाही, कारण फॉर्म ओळखीचा वाटावा म्हणून बनवला आहे। प्रोटोकॉल क्लायंट विंडोच्या आकारावरून नव्हे, सर्व्हरच्या दस्तऐवजातून निश्चित करा।
तुम्हाला खरोखर आवश्यक असलेली उत्तरे
विनंती यादी म्हणून पाठवा, कारण यादीला अर्धवट उत्तर देणे कठीण असते। बोगद्याचा प्रोटोकॉल, त्यातील पद्धत, आणि ऑपरेटर तुमच्या प्लॅटफॉर्मवर ज्या क्लायंटला समर्थन देतो तो मागा। नंतर गेटवेची ओळख आणि विश्वास सेटिंग्ज, खाते स्वरूप, आणि कनेक्शन उभे राहिल्यावर काय पोहोचता आले पाहिजे ते मागा।
पहिले तीन तुम्हाला काम करणारे प्रोफाइल अजिबात मिळेल का हे ठरवतात। शेवटचे तीन ते प्रोफाइल कामाला हवे ते करते का हे ठरवतात। उत्तर तिकिटाला जोडून ठेवा, कारण पुढची व्यक्तीही तेच सहा प्रश्न विचारेल। जिथे उत्तर नाही, तिथल्या पोकळीकडे ऑपरेटरने अजून न घेतलेला निर्णय म्हणून पाहा, तुम्ही अनुमान काढू शकता अशी गोष्ट म्हणून नाही।
| What you ask for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
गेटवे तपासणी ढिली करू नका
सर्व्हर क्लायंटसमोर आपली ओळखही सिद्ध करतो, आणि देवाणघेवाणीचा तो अर्धा भाग सजावट नाही। हट्टी प्रोफाइल जोडावे म्हणून प्रमाणपत्र तपासणी बंद करणे म्हणजे उत्तर देणाऱ्या कोणत्याही टोकाला स्वीकारणे, जिथे कोणीही पोहोचण्याचा विचार केला नव्हता तिथेही। ते खऱ्या विसंगतीचे निराकरण करण्याऐवजी लपवते, ज्यामुळे अपयश अधिक उशिरा आणि कमी स्पष्ट क्षणाकडे ढकलले जाते। ज्या प्रोफाइलला तपासणी बंद हवी असते, ते अशा गोष्टीकडे निर्देश करते जी ते तपासू शकत नाही।
विसंगती सहसा एक नाव असते, कारण एका होस्टनावासाठी जारी केलेले प्रमाणपत्र प्रोफाइल पत्ता डायल करते तेव्हा अपयशी होते। तपासणी बंद करण्याऐवजी नाव डायल करा। खाजगी प्रमाणपत्र प्राधिकरण डिव्हाइसला मूळ कधीच मिळाले नाही तेव्हा अपयशी होते, आणि उपाय म्हणजे ते मूळ मंजूर मार्गाने वितरित करणे। व्यवस्थापित वातावरण अपेक्षा करते की ऑपरेटर ओळख आणि विश्वास-अँकर पुरवेल, आणि प्रोफाइल दोन्हींचा संदर्भ देईल। फील्ड नसताना तपासणी सोडण्याऐवजी कलाकृती मागा।
प्रोफाइल जुळवा, मग प्रत्येक टप्पा सिद्ध करा
वाहक माहीत झाल्यावर त्या क्लायंटच्या नोंदवलेल्या प्रक्रियेचे अनुसरण करा आणि तो मागणारी फील्डच भरा। असल्यामुळे भरली जाणारी अतिरिक्त फील्डही चुकीची मूल्येच असतात, आणि ती आवश्यक फील्डपेक्षा उशिरा अपयशी होतात। पहिल्या यशस्वी कनेक्शननंतर प्रोफाइल न बदलता जतन करा, जेणेकरून नंतरचे संपादन चालते अशी माहीत असलेल्या गोष्टीशी तुलना करता येईल।
मग टप्प्याटप्प्याने तपासा: बोगदा प्रस्थापित होतो, वापरकर्ता प्रमाणित होतो, नेमलेला पत्ता आणि मार्ग दिसतात, आणि एक अनुमत सेवा उत्तर देते। प्रत्येक टप्पा सर्व्हरवर स्वतःची लॉग ओळ सोडतो, आणि त्या क्रमाने वाचल्यास अस्पष्ट तक्रार ठोस निरीक्षणात बदलते। प्लॅटफॉर्मने ऑपरेटरने वर्णन केलेली रचना यापुढे समर्थित केली नाही तर ती स्थलांतराची चर्चा आहे, डिव्हाइसवर सर्व जुने पर्याय सुरू करण्याचे कारण नाही। वाहक, पद्धत आणि प्रोफाइल तीन वेगळी उत्तरे आहेत, आणि चालणाऱ्या कनेक्शनमध्ये तीनही जुळतात।