پایان LCP توسط همتای مقابل روی PPTP: ابتدا MPPE را فعال کنید

پیوند احراز هویت می‌شود، کلاینت اتصال را گزارش می‌دهد و یک ثانیه بعد گزارش با پایان LCP توسط همتای مقابل بسته می‌شود. این خط از مذاکره PPP درون تونل GRE می‌آید، پس انتقال از قبل کار می‌کرد و دو سر درباره گزینه‌های پیوند اختلاف داشتند. رمزهای عبور و نشانی‌های سرور معمولاً اینجا بی‌تقصیرند. سیاست رمزنگاری نخستین چیزی است که باید مقایسه شود و در لینوکس اولین جایی که باید نگاه کرد فایل همتای 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 شکست می‌خورد. در ویندوز کنترل معادل تب امنیت ورودی 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

برای پایان دادن عمدی به یک نشست، به pid ثبت‌شده توسط pppd هدف بگیرید نه اینکه نام فرایندها را با الگو تطبیق دهید، چون کشتن هر چیزی که ppp دارد پیوندهای بی‌ربط را هم از کار می‌اندازد. PPTP منسوخ است و MS-CHAPv2 ضعیف، پس این بررسی‌ها را نگهداری پیوندی بدانید که باید کار کند، نه دلیلی برای استقرار PPTP در هیچ جای تازه.