إنهاء LCP من الطرف النظير على PPTP: فعِّل MPPE أولًا

تنجح الوصلة في المصادقة، ويُبلغ العميل عن اتصال، وبعد ثانية واحدة يُغلق السجل برسالة إنهاء LCP من الطرف النظير. يأتي هذا السطر من تفاوض PPP داخل نفق GRE، أي أن النقل كان يعمل بالفعل وأن الطرفين اختلفا حول خيارات الوصلة. عادةً لا يكون لكلمات المرور وعناوين الخادم ذنب هنا. سياسة التشفير هي أول ما يجب مقارنته، وعلى Linux فإن ملف النظير الخاص بـ pppd هو أول مكان يُنظر فيه.

ماذا يقول فشل LCP عن مرحلة PPP

يغلّف PPTP بروتوكول PPP داخل GRE: اتصال التحكم TCP 1723 يهيّئ الاتصال، ويحمل GRE الحمولة، ثم يتفاوض LCP على خيارات مثل بروتوكول المصادقة والضغط وMPPE. ينهي الطرف النظير LCP عندما يكون خيار مطلوب غير مقبول لديه. السجل الذي يكتمل فيه تبادل CHAP أو MSCHAPv2 ثم ينتهي LCP فورًا بعده هو رفض سياسة، لا فشل في الوصول. إذا لم يصل النفق إلى التفاوض إطلاقًا، فافحص pppd وإضافته قبل قراءة سطر LCP.

هناك شرطان يسهل إغفالهما. يجب أن يكون ملف 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

لإنهاء جلسة عن قصد، استهدف pid المسجل لدى pppd بدلًا من مطابقة أسماء العمليات، لأن قتل كل ما يحتوي على ppp يهدم أيضًا وصلات غير ذات صلة. صار PPTP مهجورًا وMS-CHAPv2 ضعيفًا، لذا تعامل مع هذه الفحوص كصيانة لوصلة يجب أن تظل تعمل، لا كسبب لنشر PPTP في أي مكان جديد.