PPP CHAP अकेला MPPE की आवश्यकता क्यों पूरी नहीं कर सकता

एन्क्रिप्शन पर ज़ोर देने वाला PPTP प्रोफ़ाइल आमतौर पर उसी जगह विफल होता है: PPP ऐसे प्रमाणीकरण विनिमय पर सहमत होता है जो कभी वह कुंजी सामग्री नहीं बनाता जो MPPE को चाहिए। टनल आधी जीवित दिखती है, पासवर्ड स्वीकार हो जाता है, और कोई भी ट्रैफ़िक उसे पार करने से पहले लिंक गिर जाता है। कुछ जुड़ने तक CHAP ड्रॉपडाउन की ओर हाथ बढ़ाना असली दोष छिपा देता है, और वह दोष प्रमाणीकरण विधि तथा सुरक्षा नीति के बीच का अनुबंध है। नीचे दी गई जाँचें इस तरह क्रमबद्ध हैं कि हर एक अगली से सस्ता कारण बाहर कर दे।

एक ही PPTP कनेक्शन के भीतर दो बातचीत चलती हैं

PPTP GRE टनल के भीतर सामान्य PPP सत्र ले जाता है, और दोनों अलग-अलग बातचीत करते हैं। बाहरी परत तय करती है कि पैकेट कैसे एनकैप्सुलेट होंगे और कौन-सा नियंत्रण चैनल मौजूद है; भीतरी PPP सत्र तय करता है कि साथी कौन है और ऊपर कौन-सी सुरक्षा चलती है। इसलिए पासवर्ड का अनुरोध केवल भीतरी परत के बारे में कुछ साबित करता है, और पूरा हुआ बाहरी हैंडशेक दोनों में से किसी के बारे में कुछ साबित नहीं करता। प्रोफ़ाइल यहाँ विफल होते हैं क्योंकि लोग टनल को डीबग करते हैं जबकि मतभेद PPP के भीतर बैठा होता है।

सादा CHAP RFC 1994 का चुनौती-उत्तर विनिमय है, जो साझा रहस्य और कुछ नहीं पर बना है। MS-CHAPv2 अलग संदेशों और अलग आउटपुट वाला दूसरा विनिमय है, जो RFC 2759 में मानकीकृत है। दोनों नामों का साझा शब्द ही वह एकमात्र चीज़ है जो तार पर उनमें साझा है। कोई भी नाम यह नहीं बताता कि विनिमय क्या बनाता है, और यही एकमात्र हिस्सा है जो मायने रखता है।

इसीलिए सिर्फ़ CHAP कहा गया विकल्प पुराने प्रोफ़ाइल में अस्पष्ट है। जब सर्वर MS-CHAPv2 चाहता है और क्लाइंट सादा CHAP देता है, तब भी लिंक नियंत्रण पूरा हो सकता है और पासवर्ड स्वीकार हो सकता है। विफलता बाद में आती है, जब सर्वर ऐसे विनिमय से सुरक्षा कुंजियाँ निकालने की कोशिश करता है जिसने कुछ भी नहीं बनाया।

आवश्यक विधि को उन कुंजियों से मिलाएँ जो वह बना सकती है

MPPE कुंजियाँ सामान्य रूप से PPP का गुण नहीं हैं। Microsoft CHAP परिवार के लिए व्युत्पत्ति RFC 3079 में निर्दिष्ट है, और यह इनपुट के रूप में साझा रहस्य के बजाय MS-CHAP विनिमय का आउटपुट लेती है। EAP विधियाँ दूसरे रास्ते से उसी जगह पहुँचती हैं, जहाँ प्रमाणीकरण सर्वर कुंजियों को MS-MPPE-Recv-Key और MS-MPPE-Send-Key विशेषताओं के रूप में लौटाता है। सादा CHAP दोनों में से किसी रास्ते पर नहीं आता, और यही इस बेमेल के होने का पूरा कारण है।

जो कॉन्फ़िगरेशन MPPE मांगता है पर कुंजियाँ दे सकने वाली हर विधि को अस्वीकार करता है, वह भीतर से विरोधाभासी है। pppd उस विरोधाभास को लिंक अस्वीकार करके सुलझाता है, कुंजियाँ गढ़कर नहीं, इसलिए दिखने वाला परिणाम वह सत्र है जो प्रमाणीकरण करता है और फिर नेटवर्क चरण में समाप्त हो जाता है। जब तक सर्वर कुछ भी व्युत्पन्न करने वाली एकमात्र विधियों को अस्वीकार करता है, क्लाइंट को फिर से आज़माना इसे नहीं बदलेगा।

इससे निकलने वाला नियम छोटा है: यदि प्रोफ़ाइल MPPE मांगता है, तो विधि MS-CHAP का कोई रूप या ऐसी EAP विधि होनी चाहिए जिसकी कुंजियाँ सर्वर लौटाता है। केवल MS-CHAPv2 अस्वीकार करना इसे लागू नहीं करता, क्योंकि MS-CHAPv1 भी कुंजियाँ व्युत्पन्न करता है और अलग से अस्वीकार न किए जाने तक उपलब्ध रहता है; दोनों को अस्वीकार करने से सादा CHAP और PAP बचते हैं, जो कुछ भी व्युत्पन्न नहीं करते और आवश्यकता को अपूरणीय बना देते हैं। जो आपको पसंद नहीं उन्हें सूचीबद्ध करने के बजाय स्वीकृत विधि का स्पष्ट नाम दें। क्लाइंट जुड़ सके इसके लिए एन्क्रिप्शन की आवश्यकता छोड़ देना मरम्मत नहीं, अवनति है।

क्लाइंट संपादित करने से पहले सर्वर के विकल्प पढ़ें

इनमें से ज़्यादातर बेमेल सर्वर पर दो फ़ाइलों में दिखते हैं, और उन्हें पढ़ना क्लाइंट को फिर से बनाने से कम खर्चीला है। Linux PPTP एंडपॉइंट पर संबंधित सेटिंग्स उस pppd विकल्प फ़ाइल में रहती हैं जिसे pptpd पास करता है। इसे सर्वर पर चलाएँ, क्लाइंट की स्थिति स्क्रीन से नहीं। उन पंक्तियों से शुरू करें जो सुरक्षा मोड मांगती, अस्वीकार करती या नाम देती हैं:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

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

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

PPP चरण के अनुसार विफलता का पता लगाएँ

PPP विफलताएँ चरणों में बताता है, और चरण बताता है कि अनुबंध का कौन-सा खंड टूटा। जो लिंक कभी लिंक नियंत्रण नहीं छोड़ता उसमें एनकैप्सुलेशन या बातचीत की समस्या है, जबकि जो प्रमाणीकरण करके फिर मर जाता है उसमें आमतौर पर नीति या कुंजी की समस्या होती है। जो लिंक ऊपर रहता है और कुछ नहीं ढोता वह रूटिंग पर आगे बढ़ गया है, जो अलग जाँच है।

जर्नल चरण की पंक्तियाँ रखता है, और वे ऊँचे डीबग स्तर से ज़्यादा उपयोगी हैं। PPP प्रक्रियाएँ और सुरक्षा संदेश मांगें, फिर बाकी सब से पहले प्रमाणीकरण का परिणाम पढ़ें। अंतिम पंक्तियाँ आमतौर पर उस खंड का नाम बताती हैं जिसने अस्वीकार किया:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

पुराना एंडपॉइंट बंद होने से पहले निकास की योजना बनाएँ

MPPE लिंक सुरक्षा का एक ऐतिहासिक तंत्र है, और इसकी मौजूदगी PPTP को नई तैनाती के लिए समझदार विकल्प नहीं बनाती। Microsoft का मौजूदा मार्गदर्शन पहले से ही नई रिमोट एक्सेस तैनातियों के लिए PPTP और पूर्व-साझा कुंजी वाले L2TP/IPsec के विरुद्ध सलाह देता है। पुराने एंडपॉइंट को जीवित रखना मौजूदा सेवा के बारे में निर्णय है, अगली के लिए खाका नहीं।

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

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