PPTP वर LCP समकक्षाकडून संपुष्टात: आधी MPPE सक्षम करा

लिंक प्रमाणीकरणातून जाते, क्लायंट जोडलेला असल्याचे कळवतो, आणि एका सेकंदानंतर लॉग LCP समकक्षाकडून संपुष्टात आले असे म्हणून बंद होतो। ही ओळ GRE बोगद्यातील PPP चर्चेतून येते, म्हणजे वाहतूक आधीच कार्यरत होती आणि दोन्ही टोके लिंक पर्यायांवर सहमत नव्हती। येथे पासवर्ड आणि सर्व्हर पत्ते सहसा निर्दोष असतात। एन्क्रिप्शन धोरण ही पहिली तुलना करावयाची गोष्ट आहे, आणि Linux वर pppd ची समकक्ष फाइल पाहण्याची पहिली जागा आहे।

LCP अपयश PPP टप्प्याबद्दल काय सांगते

PPTP, PPP ला GRE मध्ये गुंडाळते: TCP 1723 नियंत्रण कनेक्शन कॉल तयार करते, GRE पेलोड वाहते, आणि नंतर LCP प्रमाणीकरण प्रोटोकॉल, संकुचन आणि MPPE अशा पर्यायांवर बोलणी करते। आवश्यक पर्याय त्यांच्या बाजूला अस्वीकारार्ह असल्यास समकक्ष LCP संपुष्टात आणतो। CHAP किंवा MSCHAPv2 देवाणघेवाण पूर्ण होऊन लगेच LCP संपणारा लॉग हा धोरणाचा नकार आहे, पोहोचण्याचा अपयश नाही। बोगदा बोलणीपर्यंत पोहोचत नसेल, तर LCP ओळ वाचण्यापूर्वी pppd आणि त्याचे प्लगइन तपासा।

दोन पूर्वअटी सहज लक्षात येत नाहीत। pppd बायनरी असणे आवश्यक आहे, आणि समकक्ष फाइलमध्ये नमूद केलेले PPTP प्लगइन स्थापित असणे आवश्यक आहे; पॅकेज नसल्यास कोणताही पर्याय चर्चेत येण्यापूर्वी डायल संपतो।

MPPE त्याची मागणी करणाऱ्या बाजूला सक्षम करा

खरा निर्णय हा आहे की एन्क्रिप्शन धोरण कोणत्या टोकाकडे आहे। क्लायंट MPPE देऊ शकतो, मागू शकतो किंवा नाकारू शकतो, आणि सर्व्हरही तोच पर्याय निवडतो। दोन्ही मागणी करतात तेव्हा लिंक उभी राहते; एक मागणी करतो आणि दुसरा नाकारतो तेव्हा LCP संपतो।

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

डायल करण्यापूर्वी modprobe ppp_mppe ने मॉड्यूल लोड करा, कारण त्याशिवाय require-mppe-128 अपयशी होते। Windows वर समतुल्य नियंत्रण VPN नोंदीचा सुरक्षा टॅब आहे, जिथे सर्व्हर जे देईल ते स्वीकारण्याऐवजी एन्क्रिप्शनची मागणी करण्यास क्लायंटला सांगावे लागते। सर्व्हर अजूनही LCP संपुष्टात आणत असेल, तर MPPE अनिवार्य, ऐच्छिक की अक्षम आहे हे त्याच्या ऑपरेटरला विचारा, कारण सर्व्हर नाकारत असलेल्या संरक्षणावर क्लायंट बोलणी करू शकत नाही। संदेश नाहीसा व्हावा म्हणून एन्क्रिप्शन बंद करणे ही चुकीची दिशा आहे: ते या प्रोटोकॉलचे एकमेव संरक्षण काढून टाकते।

संपादनापूर्वी कार्यरत समकक्ष फाइल जतन करा। चुकीच्या पद्धतीने टाइप केलेली require-mppe ओळ तेच सामान्य LCP अपयश पुन्हा निर्माण करते आणि तुम्हाला सुरुवातीला परत पाठवते।

ऍपलेटऐवजी pppd चा स्वतःचा लॉग वाचा

डेस्कटॉप ऍपलेट डिस्कनेक्शन दाखवतात आणि कारण लपवतात, म्हणून एका प्रयत्नाबद्दल डेमनचा वृत्तांत वाचा। systemd प्रणालींमध्ये संदेश जर्नलमध्ये जातो; जुन्या सेटिंग्ज पारंपरिक लॉग फाइलांमध्ये लिहितात।

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

दिवसभराच्या पुनर्जोडण्यांऐवजी एका डायलभोवतीच्या खिडकीत शोधा, म्हणजे नाकारलेला पर्याय सहज दिसेल। pppd सहसा पर्यायाचे नाव आणि समकक्षाचे उत्तर सांगतो, ज्यावरून स्वतःचा प्रस्ताव बदलायचा की सर्व्हर बाजूला त्याची अट सैल करायला सांगायचे हे कळते। प्रयत्नांना वेळेच्या शिक्क्यांसह ठेवा, कारण कोणत्या ओळी कोणत्या कॉलच्या आहेत हे माहीत नसल्यास दोन लॉग तुलना करणे उपयोगी नाही। LCP ची देवाणघेवाणच दिसत नसेल, तर दोष साखळीत आधी आहे आणि MPPE संशयित नाही।

पुनर्जोडण्यांमध्ये दुरुस्ती टिकवा: हुक नावे आणि MTU

लिंक टिकून राहिल्यावर ती पुनर्जोडणी सहन करेल की नाही हे दोन तपशील ठरवतात। हुक /etc/ppp/ip-up.d आणि /etc/network/if-up.d मध्ये राहतात, आणि दोन्ही डिरेक्टरीज run-parts प्रक्रिया करते, जिचा फाइलनाव गाळणी बिंदू असलेले काहीही नाकारतो। म्हणून set-pptp.sh नावाची स्क्रिप्ट वगळली जाते, तर set-pptp चालवली जाते। स्क्रिप्टचा आतील भाग डीबग करण्यापूर्वी नाव तपासा, नंतर त्याच हुकमधून लहान MTU सेट करा जेणेकरून प्रत्येक नवीन ppp इंटरफेस ती हातच्या कमांडशिवाय वारसा घेईल।

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

सत्र जाणीवपूर्वक संपवण्यासाठी प्रक्रिया नावांचे नमुना जुळवणी करण्याऐवजी pppd ने नोंदवलेल्या pid ला लक्ष्य करा, कारण ppp असलेले सर्व मारणे असंबंधित लिंकही तोडते। PPTP कालबाह्य आहे आणि MS-CHAPv2 कमकुवत आहे, म्हणून या तपासण्या चालू राहणे आवश्यक असलेल्या लिंकची देखभाल म्हणून घ्या, नवीन ठिकाणी PPTP तैनात करण्याचे कारण म्हणून नाही।