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