LCP პარტნიორის მიერ შეწყვეტილია PPTP-ზე: ჯერ MPPE ჩართეთ

კავშირი ავთენტიფიკაციას გადის, კლიენტი აცხადებს დაკავშირებას და ერთი წამის შემდეგ ჟურნალი იხურება ჩანაწერით LCP პარტნიორის მიერ შეწყვეტილია. ეს ხაზი GRE გვირაბის შიგნით PPP მოლაპარაკებიდან მოდის, ანუ ტრანსპორტი უკვე მუშაობდა და ორი ბოლო კავშირის პარამეტრებზე არ შეთანხმებულა. პაროლები და სერვერის მისამართები აქ ჩვეულებრივ უდანაშაულოა. დაშიფვრის პოლიტიკა პირველია, რაც უნდა შევადაროთ, ხოლო Linux-ზე pppd-ის პარტნიორის ფაილი პირველი ადგილია, სადაც უნდა შევხედოთ.

რას ამბობს LCP-ის ჩავარდნა PPP ეტაპზე

PPTP PPP-ს GRE-ში ახვევს: TCP 1723 საკონტროლო კავშირი ამზადებს ზარს, GRE ატარებს დატვირთვას, შემდეგ კი LCP აწარმოებს მოლაპარაკებას ისეთ პარამეტრებზე, როგორიცაა ავთენტიფიკაციის პროტოკოლი, შეკუმშვა და MPPE. პარტნიორი LCP-ს წყვეტს, როცა სავალდებულო პარამეტრი მის მხარეს მიუღებელია. ჟურნალი, სადაც CHAP ან MSCHAPv2 გაცვლა სრულდება და LCP მაშინვე მთავრდება, პოლიტიკის უარყოფაა და არა ხელმისაწვდომობის ჩავარდნა. თუ გვირაბი მოლაპარაკებამდე საერთოდ არ აღწევს, LCP-ის ხაზის წაკითხვამდე შეამოწმეთ pppd და მისი plugin-ი.

ორი წინაპირობა ადვილად გამოგვრჩება. pppd-ის ბინარული ფაილი უნდა არსებობდეს და პარტნიორის ფაილში დასახელებული PPTP plugin-ი უნდა იყოს დაინსტალირებული; დაკარგული პაკეტი ზარს ამთავრებს ნებისმიერი პარამეტრის განხილვამდე.

ჩართეთ 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-ის ჟურნალი და არა applet-ი

სამაგიდო applet-ები გათიშვას აჩვენებენ და მიზეზს მალავენ, ამიტომ წაიკითხეთ დემონის ჩანაწერი ერთი ცდის შესახებ. systemd სისტემებში შეტყობინება journal-ში ხვდება; ძველი კონფიგურაციები ტრადიციულ ჟურნალ ფაილებში წერენ.

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

მოძებნეთ ერთი ზარის ირგვლივ ფანჯარაში და არა მთელი დღის ხელახალი დაკავშირებებში, რომ უარყოფილი პარამეტრი ადვილად შესამჩნევი იყოს. pppd ჩვეულებრივ ასახელებს პარამეტრს და პარტნიორის პასუხს, რაც გეუბნებათ, შეცვალოთ საკუთარი შეთავაზება თუ სთხოვოთ სერვერის მხარეს მოთხოვნის შემცირება. ცდები დროის ნიშნებით შეინახეთ, რადგან ორი ჟურნალის შედარება მხოლოდ მაშინ არის სასარგებლო, როცა იცით, რომელი ხაზები რომელ ზარს ეკუთვნის. თუ LCP გაცვლა საერთოდ არ ჩანს, ხარვეზი ჯაჭვში უფრო ადრეა და MPPE ეჭვმიტანილი არ არის.

შეინარჩუნეთ გასწორება ხელახალი დაკავშირებებისას: hook-ების სახელები და MTU

კავშირის დამყარების შემდეგ ორი დეტალი წყვეტს, გადაურჩება თუ არა ის ხელახალ დაკავშირებას. Hook-ები /etc/ppp/ip-up.d-სა და /etc/network/if-up.d-ში ცხოვრობენ, ორივე საქაღალდეს run-parts ამუშავებს, რომლის ფაილის სახელის ფილტრი წერტილის შემცველ ყველაფერს უარყოფს. ამიტომ set-pptp.sh სახელის მქონე სკრიპტი გამოტოვებულია, ხოლო set-pptp სრულდება. შეამოწმეთ სახელი სკრიპტის შიგთავსის გამართვამდე, შემდეგ დააყენეთ უფრო მცირე MTU იმავე hook-ის შიგნიდან, რომ ყოველმა ახალმა ppp ინტერფეისმა ის ხელით ბრძანების გარეშე მიიღოს მემკვიდრეობით.

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

სესიის განზრახ დასასრულებლად დამიზნეთ pppd-ის მიერ ჩაწერილ pid-ზე და არა პროცესების სახელების შაბლონურ შედარებაზე, რადგან ppp-ის შემცველი ყველაფრის მოკვლა დაუკავშირებელ კავშირებსაც რღვევს. PPTP მოძველებულია და MS-CHAPv2 სუსტია, ამიტომ ეს შემოწმებები მიიღეთ როგორც იმ კავშირის მოვლა, რომელიც უნდა გაგრძელდეს, და არა როგორც მიზეზი PPTP-ის ახალ ადგილას განლაგებისთვის.