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 तैनात करने के कारण की तरह नहीं।