PPTP कहता है कि आपका पासवर्ड गलत है: कौन-सा सुधार पहले आता है?
अस्वीकृत PPTP पासवर्ड आमतौर पर PPP विधि की असंगति होती है, खराब सीक्रेट नहीं। पहले बातचीत पढ़ें, फिर वह सबसे छोटा सुधार चुनें जो टिके रहे।
जो PPTP प्रोफ़ाइलें ज़िद करती हैं कि आपका पासवर्ड गलत है, वे सुनने में जितना लगता है उससे कहीं संकरा संदेश देती हैं। सीक्रेट की जाँच उस श्रृंखला के बिल्कुल अंत में होती है जो क्षमता-बातचीत से शुरू होती है, इसलिए उस श्रृंखला में पहले की कोई भी असंगति प्रमाणीकरण विफलता के रूप में सामने आती है। इसलिए पासवर्ड रीसेट करना, उसे फिर से टाइप करना या प्रोफ़ाइल फिर से बनाना कुछ नहीं बदलता। पहले बातचीत पढ़ें, फिर यह देखकर सुधार चुनें कि रास्ते का कितना हिस्सा आपके नियंत्रण में है।
सीक्रेट की जाँच कभी क्यों नहीं होती
PPP प्रमाणीकरण पर बातचीत होती है: सर्वर विधियाँ प्रस्तावित करता है, क्लाइंट वह करके उत्तर देता है जो वह कर सकता है, और कोई भी क्रेडेंशियल बदलने से पहले दोनों एक पर सहमत होते हैं। जब सर्वर केवल EAP-PEAP देता है और क्लाइंट का pppd उसे लागू नहीं करता, तो बातचीत प्रस्ताव के चरण पर ही समाप्त हो जाती है। सर्वर प्रमाणीकरण विफलता दर्ज करता है क्योंकि विफल वही चरण हुआ, इसलिए नहीं कि पासवर्ड की तुलना की गई और वह अपर्याप्त मिला।
इसीलिए गलत पासवर्ड और विधि की असंगति, दोनों में त्रुटि एक जैसी होती है। केवल लॉग ही उनमें अंतर करता है, और वह भी तभी जब क्लाइंट को विस्तृत होने की अनुमति हो।
बातचीत पढ़ें, आखिरी त्रुटि नहीं
कनेक्शन को डिबगिंग चालू करके अग्रभूमि में चलाएँ और प्रमाणीकरण की पंक्तियाँ ऊपर से पढ़ें। लॉग में प्रस्तावित विधि, स्वीकृत विधि और वह जगह लिखी होती है जहाँ अदला-बदली रुकी। जो प्रोफ़ाइल CHAP या MSCHAPv2 से कभी बाहर नहीं निकलती, जबकि सर्वर PEAP की अपेक्षा करता है, वह विधि की समस्या है, क्रेडेंशियल की नहीं। उस लॉग की आखिरी पंक्ति वह जगह है जहाँ क्लाइंट ने हार मानी, वह नहीं जहाँ कारण है।
sudo pppd call provider debug nodetachउस आउटपुट को रख लें। यह नेटवर्क मालिक को सर्वर नीति बदलने से पहले चाहिए होने वाला प्रमाण भी है, और यह उस सवाल का फैसला करता है कि पासवर्ड आखिरकार खेल में था या नहीं।
दूसरा कारण सीक्रेट फ़ाइल में छिपा है
अगर लॉग दिखाता है कि विधियाँ सहमत हैं, तो उस फ़ाइल को देखें जो सीक्रेट रखती है। पासवर्ड फ़ील्ड में लिखी गई नई पंक्ति या अंत में बची जगह पासवर्ड के हिस्से के रूप में भेजी जाती है, इसलिए सर्वर आपके टाइप किए हुए से अलग स्ट्रिंग की तुलना करता है। एडिटर में फ़ाइल सही दिखती है, और ठीक इसी कारण यह इतने सारे प्रयासों के बाद भी बची रहती है।
sudo cat -A /etc/ppp/chap-secretsउस आउटपुट में हर पंक्ति का अंत डॉलर चिह्न बताता है। उस चिह्न से पहले कुछ रखने वाले पासवर्ड फ़ील्ड, या फ़ील्डों के बीच भटकी हुई जगह, को उसी उद्धरण के साथ फिर से लिखना होगा जो टूल दस्तावेज़ करता है।
सर्वर किसका है, उसके अनुसार सुधार चुनें
अगर सर्वर आपका है, उस खाते के लिए MSCHAPv2 की अनुमति देना सबसे छोटा बदलाव है, और आपको दर्ज करना चाहिए कि आपने जानबूझकर कमज़ोर विधि स्वीकार की। अगर यह किसी और का है, तो EAP-PEAP लागू करने वाला क्लाइंट ईमानदार सुधार है; pppd को पैच करने से असंगति आपकी रखरखाव समस्या बन जाती है। अगर प्रोटोकॉल का चुनाव अभी खुला है, तो PPTP डिज़ाइन का सबसे कमज़ोर हिस्सा है और पैच किए गए क्लाइंट को जीवित रखने से माइग्रेशन आमतौर पर सस्ता पड़ता है। उस निर्णय को प्रोफ़ाइल के बगल में लिखें ताकि अगला व्यक्ति इसे फिर से न खोले।
आप जो भी रास्ता चुनें, बाद में दूसरे नेटवर्क पर दूसरी मशीन से परखें। सहेजी गई प्रोफ़ाइल पुरानी विधि प्रस्तावित करती रह सकती है और सुधारे गए सर्वर को टूटा हुआ दिखा सकती है। फिर डिबग सेटिंग हटा दें, क्योंकि विस्तृत PPP लॉग साझा वर्कस्टेशन पर आपकी इच्छा से अधिक कैद कर सकते हैं।