MSCHAPv2 कुनै VPN प्रोटोकल होइन: पहिले सुरुङको बारेमा सोध्नुहोस्

प्रयोगकर्तानाम र पासवर्डहरू एउटा वाहकभित्र यात्रा गर्छन्, र MSCHAPv2 ले यात्रा गर्ने विधिको नाम मात्र बताउँछ। क्लाइन्ट प्रोफाइल छान्नु अघि कुन सुरुङले यसलाई बोक्छ सोध्नुहोस्, किनकि त्यही खाता शृंखला कोडको एउटै लाइन नबाड्ने व्यवस्थामा पनि देखिन्छ। तपाईंलाई दिइने हरेक प्रोफाइलले दुवै निर्णय इन्कोड गर्छ, निर्देशन पत्रले तीमध्ये एउटा मात्र छापे पनि। तलको क्रम त्यही हो जसको उत्तर अपरेटरले अनुमान नगरी दिन सक्छ र जुन तपाईंले प्याकेट नसमाती जाँच्न सक्नुहुन्छ।

प्रमाणीकरण सुरुङभित्र चल्छ

VPN ले एउटै जस्तो देखिने दुई निर्णय लिन्छ: दुवै पक्षले सुरक्षित च्यानल कसरी बनाउँछन्, र व्यक्तिले त्यसभित्र आफ्नो परिचय कसरी प्रमाणित गर्छ। दोस्रो निर्देशन पत्रमा छापिन्छ किनकि त्यही मानिसले टाइप गर्छ। पहिलोले कुनै पनि क्लाइन्ट काम गर्छ कि गर्दैन भन्ने तय गर्छ, र मानिसहरूले त्यही छोड्छन्। अपरेटरलाई पहिले वाहक र त्यसपछि विधिको नाम बताउन भन्नुहोस्, त्यही क्रममा। दुई जडानले एउटै खाता नाम र एउटै पासवर्ड माग्न सक्छन्, तर लगइन बाकसको तल कुनै कार्यान्वयन बाँड्दैनन्।

त्यसैले सहकर्मीको चल्ने फोनबाट प्रतिलिपि गरिएका सेटिङहरू सर्भरले दुवै प्रमाणहरू स्वीकार गर्दा पनि तपाईंको फोनमा असफल हुन सक्छन्। फरक कहिल्यै प्रमाण थिएन; त्यसलाई बेर्ने प्रोफाइल थियो। दुवै पक्ष सही छन् र केही पनि जोडिँदैन सामान्यतया यही भ्रम हो, र वाहकको नाम लिने बित्तिकै त्यो फुक्छ।

त्यही विधि देखिने तीन ठाउँ

PPP मा प्रमाणीकरण चरण लिङ्क नभएसम्म पर्खन्छ, र RFC 2759 ले MS-CHAPv2 लाई त्यही चरण भनी परिभाषित गर्छ, त्यसैले यो विधि L2TP र पुराना PPTP तैनाथीहरूमा देखिन्छ। सुरुङ पहिले टुंगिन्छ र PPP वार्ता त्यसभित्र हुन्छ, त्यसैले असफल PPP चरणले सर्भर लगमा सुरुङ स्थापित भएजस्तो छाड्न सक्छ। प्रमाणहरू अस्वीकार भए भन्ने निष्कर्ष निकाल्नु अघि ती दुई चरणहरू अलग-अलग पढ्नुहोस्। त्यसैले L2TP का लागि कन्फिगर गरिएको क्लाइन्ट पूर्ण रूपमा सही हुन सक्छ र तैपनि IKEv2 मात्र बोल्ने गेटवेका लागि गलत क्लाइन्ट हुन सक्छ।

IKEv2 ले बरु EAP-MSCHAPv2 लाई कुञ्जी आदानप्रदानभित्र राख्छ, त्यसैले त्यही प्रमाण फरक क्षणमा असफल हुन्छ र सत्र त्रुटिको सट्टा प्रमाणीकरण त्रुटिका रूपमा देखा पर्छ। Android को प्लेटफर्म IKEv2 प्रोफाइल दैनिक उदाहरण हो, र यसले PPP विकल्पको सट्टा सर्भर प्रमाणपत्र वा पहिचानकर्ता माग्छ। खाता नाम दुवै व्यवस्थामा समान हुन्छ, त्यसैले तपाईंसँग कुन छ भन्न सक्दैन। यो केवल अपरेटरका समर्थित प्रोटोकलहरूको सूचीले तय गर्छ।

TLS आधारित VPN ले तेस्रो व्यवस्था थप्छ, आफ्नै प्रयोगकर्तानाम र पासवर्ड फिल्डसहित र आदानप्रदानमा कतै पनि MS-CHAPv2 बिना। त्यसैले पासवर्ड बाकस देख्नु त्यसपछाडिको प्रोटोकलको प्रमाण होइन, किनकि फारम परिचित देखिनका लागि बनाइएको छ। प्रोटोकल क्लाइन्ट विन्डोको आकारबाट होइन, सर्भरको कागजातबाट पुष्टि गर्नुहोस्।

तपाईंलाई साँच्चै आवश्यक उत्तरहरू

अनुरोध सूचीका रूपमा पठाउनुहोस्, किनकि सूचीलाई आधा उत्तर दिन गाह्रो हुन्छ। सुरुङको प्रोटोकल, त्यसभित्रको विधि, र अपरेटरले तपाईंको प्लेटफर्ममा समर्थन गर्ने क्लाइन्ट माग्नुहोस्। त्यसपछि गेटवेको पहिचान र विश्वास सेटिङ, खाताको ढाँचा, र जडान उठेपछि के पुग्न सकिनु पर्ने हो त्यो माग्नुहोस्।

पहिलो तीनले तपाईंलाई काम गर्ने प्रोफाइल नै मिल्छ कि मिल्दैन तय गर्छन्। अन्तिम तीनले त्यो प्रोफाइलले कामलाई चाहिने कुरा गर्छ कि गर्दैन तय गर्छन्। उत्तरलाई टिकटसँग जोडेर राख्नुहोस्, किनकि अर्को व्यक्तिले पनि त्यही छ प्रश्न सोध्नेछ। जहाँ उत्तर छैन, त्यहाँ त्यो खाली ठाउँलाई अपरेटरले अझै नलिएको निर्णय मान्नुहोस्, तपाईंले अनुमान गर्न सक्ने कुरा होइन।

गेटवे प्रमाणीकरण खुकुलो नपार्नुहोस्

सर्भरले क्लाइन्टसमक्ष पनि आफ्नो पहिचान प्रमाणित गर्छ, र आदानप्रदानको त्यो आधा सजावट होइन। हठी प्रोफाइल जोडियोस् भनेर प्रमाणपत्र जाँच बन्द गर्नु भनेको उत्तर दिने जुनसुकै अन्त्य बिन्दुलाई स्वीकार गर्नु हो, कसैले पुग्न नचाहेको ठाउँ पनि। यसले वास्तविक बेमेल समाधान नगरी लुकाउँछ, जसले असफलतालाई अझ ढिलो र कम स्पष्ट क्षणतिर धकेल्छ। जुन प्रोफाइललाई जाँच बन्द चाहिन्छ, त्यो आफूले प्रमाणित गर्न नसक्ने कुरातिर सङ्केत गर्छ।

बेमेल सामान्यतया एउटा नाम हुन्छ, किनकि एउटा होस्टनामका लागि जारी गरिएको प्रमाणपत्र प्रोफाइलले ठेगाना डायल गर्दा असफल हुन्छ। जाँच बन्द गर्नुको सट्टा नाम डायल गर्नुहोस्। निजी प्रमाणपत्र प्राधिकरण यन्त्रलाई कहिल्यै मूल दिइएन भने असफल हुन्छ, र समाधान त्यो मूललाई स्वीकृत मार्गबाट वितरण गर्नु हो। व्यवस्थापित वातावरणले अपरेटरले पहिचान र विश्वास-एङ्कर उपलब्ध गराउने, र प्रोफाइलले दुवैलाई सन्दर्भ गर्ने अपेक्षा गर्छ। फिल्ड अनुपस्थित हुँदा प्रमाणीकरणबाट पछि हट्नुको सट्टा कलाकृति माग्नुहोस्।

प्रोफाइल मिलाउनुहोस्, त्यसपछि हरेक चरण प्रमाणित गर्नुहोस्

वाहक थाहा भएपछि त्यो क्लाइन्टको अभिलेखित प्रक्रिया पछ्याउनुहोस् र त्यसले माग्ने फिल्ड मात्र भर्नुहोस्। छन् भनेर भरिने अतिरिक्त फिल्ड पनि गलत मान नै हुन्, र ती अनिवार्यभन्दा ढिलो असफल हुन्छन्। पहिलो सफल जडानपछि प्रोफाइल नबदली सुरक्षित गर्नुहोस्, ताकि पछिको सम्पादन काम गर्छ भनी जानिएको कुरासँग तुलना गर्न सकियोस्।

त्यसपछि चरणबद्ध रूपमा जाँच्नुहोस्: सुरुङ स्थापित हुन्छ, प्रयोगकर्ता प्रमाणित हुन्छ, तोकिएको ठेगाना र मार्ग देखा पर्छन्, र एउटा अनुमत सेवाले उत्तर दिन्छ। हरेक चरणले सर्भरमा आफ्नै लग लाइन छोड्छ, र तिनलाई क्रममा पढ्दा अस्पष्ट गुनासो ठोस भेटमा बदलिन्छ। प्लेटफर्मले अपरेटरले वर्णन गरेको व्यवस्था अब समर्थन गर्दैन भने त्यो बसाइँसराइको कुरा हो, यन्त्रमा सबै पुराना विकल्प खोल्ने कारण होइन। वाहक, विधि र प्रोफाइल तीन अलग उत्तर हुन्, र चल्ने जडानमा ती तीनै मिल्छन्।