لماذا لا يستطيع PPP CHAP وحده تلبية متطلب MPPE

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

مفاوضتان تجريان داخل اتصال PPTP واحد

يحمل PPTP جلسة PPP عادية داخل نفق GRE، والاثنان يتفاوضان بشكل منفصل. تحدد الطبقة الخارجية كيفية تغليف الحزم وأي قناة تحكم توجد؛ وتحدد جلسة PPP الداخلية من هو النظير وما الحماية التي تسير فوقه. لذلك لا تثبت مطالبة كلمة المرور شيئًا عن الطبقة الداخلية إلا، ومصافحة خارجية مكتملة لا تثبت شيئًا عن أي منهما. تفشل الملفات هنا لأن الناس يستكشفون أخطاء النفق بينما يقع الخلاف داخل PPP.

CHAP العادي هو تبادل التحدي والاستجابة في RFC 1994، مبني على سر مشترك ولا شيء آخر. MS-CHAPv2 تبادل مختلف برسائل مختلفة ومخرجات مختلفة، موحّد في RFC 2759. الكلمة المشتركة في الاسمين هي الشيء الوحيد المشترك بينهما على السلك. لا يخبرك أي من الاسمين بما ينتجه التبادل، وهو الجزء الوحيد المهم.

لهذا السبب يكون الخيار المسمى ببساطة CHAP غامضًا في ملف قديم. عندما يريد الخادم MS-CHAPv2 ويقدم العميل CHAP العادي، يمكن أن يكتمل التحكم بالرابط ويمكن أن تُقبل كلمة المرور. يصل الفشل لاحقًا، عندما يحاول الخادم استخلاص مفاتيح الحماية من تبادل لم ينتج أي شيء.

طابق الطريقة المطلوبة مع المفاتيح التي يمكنها إنتاجها

مفاتيح MPPE ليست خاصية لـ PPP عمومًا. بالنسبة لعائلة Microsoft CHAP يُحدَّد الاشتقاق في RFC 3079، وهو يأخذ كمدخل مخرجات تبادل MS-CHAP بدلًا من سر مشترك. تصل طرق EAP إلى الموضع نفسه عبر مسار مختلف، حيث يعيد خادم المصادقة المفاتيح كخصائص MS-MPPE-Recv-Key و MS-MPPE-Send-Key. لا يظهر CHAP العادي في أي من المسارين، وهذا هو السبب الكامل لوجود عدم التطابق.

التكوين الذي يتطلب MPPE مع رفض كل طريقة قادرة على توفير المفاتيح متناقض داخليًا. يحل pppd هذا التناقض برفض الرابط، لا باختلاق مفاتيح، لذا فالنتيجة المرئية جلسة تصادق ثم تنتهي أثناء مرحلة الشبكة. لن تغير إعادة محاولة العميل ذلك ما دام الخادم يرفض الطرق الوحيدة التي تشتق أي شيء.

القاعدة التي تتبع ذلك قصيرة: إذا كان الملف يتطلب MPPE، فيجب أن تكون الطريقة أحد أنواع MS-CHAP أو طريقة EAP يعيد الخادم مفاتيحها. رفض MS-CHAPv2 فقط لا يفرض ذلك، لأن MS-CHAPv1 يشتق المفاتيح أيضًا ويبقى متاحًا ما لم يُرفض بشكل منفصل؛ ورفض كليهما يترك CHAP العادي و PAP، وهما لا يشتقان شيئًا ويجعلان المتطلب غير قابل للتحقيق. سمِّ الطريقة المقبولة صراحة بدلًا من سرد التي لا تحبها. إسقاط متطلب التشفير لجعل العميل يتصل هو تخفيض، وليس إصلاحًا.

اقرأ خيارات الخادم قبل تعديل العميل

معظم حالات عدم التطابق هذه مرئية على الخادم في ملفين، وقراءتها تكلف أقل من إعادة بناء عميل. على نقطة نهاية PPTP في Linux تعيش الإعدادات ذات الصلة في ملف خيارات pppd الذي يمرره pptpd. شغّله على الخادم، لا من شاشة حالة العميل. ابدأ بالأسطر التي تتطلب وضع حماية أو ترفضه أو تسميه:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

اقرأ المخرجات كعقد لا كقائمة أعلام. السطر الذي يتطلب MPPE مع رفض نوعي MS-CHAP لا يمكن لأي عميل تلبيته، وغياب المتطلب لطريقة MS-CHAP يترك الباب مفتوحًا لتبادلات لا تنتج مفاتيح. ثم تحقق من يُسمح له بالمصادقة أصلًا، وهو ما يقرره ملف الأسرار:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

اكتب ثلاث قيم قبل تغيير أي شيء: البروتوكول الخارجي، وطريقة المصادقة التي يتطلبها الخادم، وما إذا كانت الحماية إلزامية أم اختيارية. هذه الثلاث تحدد كل قرار لاحق، وتخمينها من مربع حوار العميل هو كيف ينتهي الملف نصف مهيأ. أبقِ الملف مفتوحًا أثناء عملك، لأن القسم التالي يحتاج القيم الثلاث نفسها.

حدد موقع الفشل حسب مرحلة PPP

يبلغ PPP عن الأعطال على شكل مراحل، والمرحلة تخبرك أي بند من العقد انكسر. الرابط الذي لا يغادر التحكم بالرابط أبدًا لديه مشكلة تغليف أو تفاوض، بينما الرابط الذي يصادق ثم يموت عادة ما تكون لديه مشكلة سياسة أو مفتاح. الرابط الذي يبقى قائمًا ولا يحمل شيئًا قد انتقل إلى التوجيه، وهو تحقيق مختلف.

يحتفظ السجل بأسطر المراحل، وهي أنفع من مستوى تصحيح أعلى. اطلب عمليات PPP ورسائل الحماية، ثم اقرأ نتيجة المصادقة قبل أي شيء آخر. عادة ما تسمي الأسطر الأخيرة البند الذي رفض:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

في تلك المخرجات، ابحث أولًا عن نتيجة المصادقة ثم عن شكوى بأن الحماية كانت مطلوبة لكن لم يتم التفاوض عليها. الرسالة الثانية هي بصمة التناقض أعلاه، ولا شيء من إعادة المحاولة يزيلها ما دام الخادم يرفض الطريقة الوحيدة القادرة على إنتاج المفاتيح. يجدر تسمية فخين: رفع مستوى التصحيح دون قراءة أسطر المراحل ينتج ضجيجًا، والتقاط مادة التحدي أو كلمات المرور يحول مهمة تكوين إلى تسريب بيانات اعتماد. سجّل تلك المرحلة قبل تغيير أي خيار.

خطط للخروج قبل إيقاف نقطة النهاية القديمة

MPPE آلية تاريخية لحماية الرابط، ووجودها لا يجعل PPTP خيارًا معقولًا لنشر جديد. إرشادات Microsoft الحالية تنصح بالفعل ضد PPTP وضد L2TP/IPsec بمفتاح مشترك مسبقًا لعمليات نشر الوصول عن بُعد الجديدة. إبقاء نقطة نهاية قديمة حية قرار يتعلق بخدمة قائمة، وليس قالبًا للتالية.

عندما يتعين بقاء نقطة النهاية، اكتب العقد: البروتوكول الخارجي، وطريقة المصادقة المطلوبة، والحماية الإلزامية، وإصدار العميل الذي يتفاوض عليها. وعندما يمكنها الرحيل، اختر هوية بوابة البديل، ومصادقة عميله، وأين ستقيم بيانات الاعتماد قبل لمس الملف القديم. ثم خطط للمسارات و DNS والموارد المسموح لكل مستخدم بالوصول إليها. تحقق من العميل المقصود مقابل متطلبات المالك لا مقابل اتصال عامل.

يجب أن يبقى الرفض المتعمد رفضًا، لأن التراجع إلى وضع غير محمي لتمرير اختبار يحول فشل سياسة إلى تعرض. الحالة المكتملة هي عقد مدعوم وموثق، وليس أصغر مجموعة تغييرات تجعل اتصالًا قديمًا واحدًا ينجح. اترك الملف القديم في مكانه، غير مستخدم وموثق، حتى يجتاز البديل الفحوص نفسها.