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 نوي ځای کې ځای پرځای کولو دلیل۔