أخطاء كتابة GRE في pptpd ليست مشكلة كلمة مرور

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

رسالتان، خطآن مختلفان

فشل القراءة يعني أن حزم GRE لا تصل أبدًا إلى الخدمة، أو تُسقط في الطريق إلى الداخل. قد يبدو اتصال التحكم سليمًا تمامًا بينما لا يعبر شيء مسار البيانات. المصادقة هي الشيء الوحيد الذي نجح بشكل مؤكد.

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

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

البروتوكول 47 ليس المنفذ 47

يستخدم PPTP بروتوكول TCP 1723 لإعداد الاتصال وGRE لحمل الحمولة. GRE هو بروتوكول IP رقم 47، وليس رقم منفذ، لذا فإن قاعدة جدار الحماية التي تفتح المنفذ 47 لا تسمح بشيء مفيد.

يحتاج الموجّه في المسار إلى ميزة تمرير PPTP أو سماح صريح بـ GRE. بدون ذلك يكتمل مصافحة TCP ولا ينقل النفق أي حزمة، وهو ما ينتج فشل القراءة أعلاه بالضبط. قواعد المنفذ 47 في جدار الحماية هي أكثر أمسية مهدورة في هذا البروتوكول.

راقب الاتجاهين في الوقت نفسه على الخادم بدلًا من تخمين الجانب الذي يسقط الحركة: tcpdump -ni any port 1723 or proto gre.

إذا أظهر 1723 إعداد الاتصال بينما يبقى GRE صامتًا، فالمنع أعلى من المضيف. وإذا وصل GRE وما زالت الخدمة تفشل، فالمشكلة محلية والخيارات هي المكان التالي للنظر.

اسمح بـ GRE حيث يمرر المضيف فعليًا

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

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

احفظ القاعدة عبر خدمة جدار الحماية في التوزيعة بدلًا من إعادة تشغيلها بعد كل إقلاع. على مضيف nftables، طابق ip protocol gre في سلسلتي الإدخال والتوجيه.

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

طابق الخيارات مع العميل الذي لديك فعليًا

إصلاح التقرير الآخر موجود في /etc/ppp/pptpd-options، حيث يرفض الوصفة PAP وCHAP وMSCHAP، ويُعلّق أسطر require المطابقة ويحتفظ بـ MPPE الحافظ للحالة. كُتبت تلك الوصفة لمزيج عملاء واحد، ونسخها بشكل أعمى يكسر الحالة الشائعة. اقرأ أسطر الرفض كبيان عن العملاء الذين كان لدى المؤلف، لا كتوصية.

يحتاج عميل Windows عادةً إلى MS-CHAPv2 مع MPPE-128. احتفظ بهذين الشرطين وأزل فقط الخيارات التي لا يستطيع العميل التفاوض عليها فعليًا.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

اقرأ رقم خطأ العميل

رقم العميل يضيّق المرحلة أسرع من سجل الخادم. اقرأه قبل أي شيء آخر. 691 يعني رفض بيانات الاعتماد، و721 يعني أن الخادم لم يجب أبدًا، و619 يعني أن الاتصال انقطع. دقيقتان مع الرقم توفران ساعة مع التكوين.

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

عندما ينجح تسجيل الدخول ولا تتحرك أي حركة، يبقى GRE المشتبه به. تلك هي اللحظة للعودة إلى الالتقاط بدلًا من مخزن بيانات الاعتماد.