फक्त 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 आणि प्रत्येक वापरकर्त्याला प्रवेशाधिकार असलेली संसाधने योजा। इच्छित क्लायंट चालू असलेल्या कनेक्शनशी नाही, मालकाच्या आवश्यकतांशी पडताळा।

हेतुपूर्वक केलेला नकार नकारच राहिला पाहिजे, कारण चाचणी उत्तीर्ण व्हावी म्हणून असुरक्षित मोडमध्ये माघार घेणे धोरणाचे अपयश उघडकीत बदलते। पूर्ण झालेली स्थिती हा समर्थित, दस्तऐवजीकृत करार आहे, एक जुने कनेक्शन यशस्वी करणारा सर्वात लहान बदलांचा संच नाही। बदली त्या तपासण्या उत्तीर्ण होईपर्यंत जुने प्रोफाइल त्याच्या जागी, न वापरलेले आणि दस्तऐवजीकृत ठेवा।