تتبع حزم التحكم في OpenVPN: tls-auth قبل TLS

عادةً ما يُبلَّغ عن فشل tls-auth على أنه مشكلة مصافحة، لكنه لم يكن كذلك قط. تُفحص HMAC على حزمة التحكم قبل حدوث أي معالجة لـ TLS، لذلك يُنتج مفتاح أو اتجاه غير متطابق فشلاً يبدو كمشكلة شهادة ويُحسم قبل ذلك بطبقتين. التعامل مع الغلاف ككائن قائم بذاته يجعل التشخيص قصيراً: اقرأ الحقول، وتأكد من أن الفحص يحدث مبكراً، ثم قارن الأمور الثلاثة التي يجب أن يتفق عليها الطرفان.

اقرأ الغلاف بالترتيب الذي يُبنى به

تحمل حزمة التحكم معرّف جلسة، وHMAC الاختيارية الخاصة بـ tls-auth، ومعلومات إعادة التشغيل والإقرار، ومعرّف رسالة موثوق، وتأتي حمولة نوع الرسالة بعد ذلك. عندما تكون الرسالة رسالة مصافحة، تكون الحمولة في هذه الحالة نص TLS المشفّر. هذه هي العلاقة كاملة: مواد TLS تنتقل داخل رسالة يحميها الغلاف أصلاً. راجع مرجع بروتوكول شبكة OpenVPN الذي يسرد حقول قناة التحكم بهذا الترتيب.

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

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

أثبت أن الفحص يحدث قبل المصافحة

يمكن للمستقبل الذي يملك المفتاح المشترك أن يتحقق من HMAC ويرفض حزمة مزوّرة فوراً، دون تخصيص حالة مصافحة أو القيام بعمل بالمفتاح العام. تشمل الحماية أيضاً حزم المصافحة الأولى، ولهذا بالضبط يظهر مفتاح خاطئ على هيئة اتصال فاشل بدلاً من خطأ مصادقة متأخر.

ارفع مستوى إسهاب الخادم الخفي وراقب قناة التحكم بدلاً من جهاز tun:

openvpn --config /etc/openvpn/server.conf --verb 6

ما تبحث عنه هو فشل تحقق HMAC في قناة التحكم يُبلَّغ عنه على مستوى الحزمة، قبل أي تنبيه TLS. وجود تنبيه TLS في السجل يعني أن الغلاف قُبل وأن الفشل انتقل إلى الداخل، وهي تحقيق مختلف بإصلاح مختلف.

توجد أيضاً معالجة الاتجاه هنا. عندما يُستخدم ملف مفتاح ثابت مع tls-auth، يأخذ الطرفان اتجاهي مفتاح متعاكسين، ويستخدم البروتوكول هذا الانقسام حتى لا يمكن إعادة إرسال حزمة ملتقطة إلى مرسلها. عكس الاتجاه يُبقي المفتاح نفسه ويُفشل كل حزمة رغم ذلك. غيّر طرفاً واحداً في كل مرة، ثم أعد تشغيل الخادمين الخفيين معاً حتى يُحمَّل الزوج في وقت واحد.

طابق المفتاح والاتجاه والـ digest على الطرفين

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

ولّد السر المشترك بالأداة لا بالمحرر، وأبقِ أذوناته ضيقة:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

لا تخلط بين tls-auth وtls-crypt. كلاهما يحمي قناة التحكم، لكن tls-crypt يشفرها أيضاً ويخفي المصافحة عن المراقبين، ويستبدل انقسام الاتجاه بمعالجة مفاتيح خاصة به. الملف الشخصي الذي يستخدم أحدهما لن يتوافق مع طرف مُعدّ للآخر، ولا يسدّ أي قدر من ضبط الـ digest تلك الفجوة.

أعد إنتاج وسم فقط من الصيغة الحقيقية

إعادة الإنتاج المطابقة بالبايت مهمة منفصلة عن تشغيل VPN، وهي تعمل فقط مع المدخلات الحقيقية: التنفيذ والإصدار الذي بنى الحزمة، والـ digest المختار، والاتجاه، والبايتات الفعلية بما فيها معرّف الجلسة ومصفوفة الإقرار. العرض النصي لقائمة الحقول ليس تلك البايتات.

طول الوسم يتبع الـ digest، لذا ينكسر افتراض الطول الثابت في اللحظة التي يغيّره فيها أحد. جزّئ الحزمة كما يفعل التنفيذ، لا كما يعرضها جدول في تدوينة، وقارن بلقطة مأخوذة من الطرف نفسه بدلاً من توقع استنتجته يدوياً.

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

تراجع عن عدم التطابق دون إزالة الحماية

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

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

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