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 तैनाथ गर्ने कारण होइन।