tls-auth key-direction: يجب أن يختلف 0 و1، لا أن يتطابقا
مع tls-auth يحتاج الطرفان إلى اتجاهين متعاكسين، 0 و1، أو أن يحذف كلاهما الإعداد. الرقم نفسه يفشل، وtls-crypt لا يستخدمه أبدا.
أحد طرفي النفق يوقّع قناة التحكم بفتحة مفتاح لا يفحصها الطرف الآخر أبدا، فيموت الاتصال بخطأ مصادقة قبل تبادل شهادة واحدة. هكذا يبدو تعارض الاتجاه في tls-auth، وهو حتمي: الملفان نفسهما يفشلان في كل محاولة ومن كل شبكة. لا يذكر شيء في السجل الخيار الذي تبحث عنه، ولهذا يعيد الناس بناء المفاتيح ويصدرون شهادات لم تكن معطوبة أصلا. الحل أن تجعل الطرفين متكاملين، أو أن تترك كليهما ثنائي الاتجاه، بدلا من إضعاف التحقق.
الفشل يقع قبل الشهادات
مع tls-auth يحمل الطرفان المفتاح المشترك نفسه، ويستخدم كل منهما إحدى فتحتين مشتقتين منه: فتحة توقّع حزم التحكم الصادرة، والأخرى تتحقق من الواردة. الاتجاه 0 والاتجاه 1 يعيّنان هذين الدورين بترتيب معاكس، لذا يجب أن يكون الزوج متكاملا لتتطابق فحوص HMAC. وعندما يُعكس التعيين على أحد الطرفين، يبحث المستقبل عن توقيع في الفتحة الخطأ ويرفض الحزمة. تنتهي الجلسة عند ذلك، ولهذا يتعلق الخطأ بمصادقة الحزم لا بشيء ينتجه مخزن الشهادات.
الحتمية مهمة للتشخيص، لأن مشكلة التوقيت أو المسار تترك أثرا مختلفا: انقطاعات متقطعة، أو فشل اتجاه واحد، أو جلسة تموت على شبكة معينة فقط. تعارض الاتجاه يفشل في أول مصافحة كل مرة، ويفشل بالطريقة نفسها على جهاز آخر يحمل الملفين نفسيهما. اقرأ السجل عند --verb 4 ثم ابحث عن أول حزمة مرفوضة بدلا من السطر الأخير. إذا حدث ذلك الرفض قبل أي تبادل للشهادات، فالمفتاح المشترك واتجاهه هما الأمران الجديران بالفحص.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
أين يعيش الرقم
دليل OpenVPN 2.6 يوثّق مكانين للاتجاه: الوسيطة الثانية لخيار tls-auth حين يكون المفتاح في ملف مستقل، وسطر key-direction مستقل حين يكون المفتاح مضمنا في الملف الشخصي. كلاهما يضبط القيمة نفسها، لذا ينبغي للملف الشخصي أن يستخدم صيغة واحدة أو الأخرى، لا الاثنتين أبدا. الحذف خيار أيضا، وهو يضع الطرفين في ترتيب ثنائي الاتجاه يعمل حين لا يسمّي أي طرف اتجاها. الطرفان الحاملان للرقم نفسه ليسا في ذلك الترتيب: كل منهما يتوقع التوقيع في فتحة والتحقق في الأخرى، وكلاهما يفعل ذلك بالاتجاه نفسه.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
الصيغة المضمّنة توجيه في سطر مستقل، وليست سمة على وسم فتح كتلة المفتاح، وإضافة وسيطة إلى ذلك الوسم خطأ لا تغيير في الاتجاه. الموضع مهم أيضا: التوجيه يقع خارج الكتلة التي ينتمي إليها، لذا تُقرأ القيمة المكتوبة داخل الكتلة كمادة مفتاح. انسخ الترتيب الذي قصده موزّع الملف الشخصي بدلا من اختراع اقتران، لأن ملفا يعمل مع خادم قد يكون منسوخا على الجانب الآخر بالفعل.
ما يتركه الخيار دون مساس
إنه لا يشفّر حركة التطبيقات. يضع tls-auth HMAC حول حزم قناة التحكم، بينما تُحمى قناة البيانات بمفاتيح جلسة يُتفاوض عليها أثناء المصافحة، لذا فسؤال الإنتاجية أو التشفير لا علاقة له برقم الاتجاه. كما لا يضيف الإعداد طبقة تشفير ثانية، وهذا هو الافتراض الذي يدفع الناس للبحث عن مفتاح أطول.
لا ينطبق على tls-crypt، آلية أخرى لقناة التحكم لها خياراتها ومعالجتها للمفاتيح، ولا يقول شيئا عن هوية شهادة أي طرف. لذا فإن تطابق الاتجاه العامل يثبت فقط أن الطرفين متفقان على كيفية مصادقة قناة التحكم، لا أن سلسلة الثقة قد تم التحقق منها.
وحّد الزوج ثم أعد الاتصال
قارن التكوينين قبل تغيير أي منهما، لأن تعديل الجانب الصحيح أصلا يضاعف العمل. يبيّن grep أدناه الآلية التي يختارها كل ملف؛ ويبيّن التشغيل المطوّل ما إذا كانت قناة التحكم قد صادقت أصلا. احتفظ بالمخرجين كليهما، حتى تُقارن التغييرة التالية بحالة معروفة.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
أعد تشغيل الطرفين بعد أي تغيير، لأن هذه الخيارات تُقرأ مرة واحدة عند البدء، وإعادة تحميل أحد الجانبين تترك الزوج غير متسق طوال عمر الجلسة القديمة. إذا كان النشر يعمل حاليا دون اتجاه مهيّأ، فإن إضافة الإعداد إلى أحد الطرفين تعيد إنتاج الفشل الذي بدأت به؛ فإما أن تترك كليهما أو تهيّئ كليهما. غيّر طرفا واحدا في كل مرة واحتفظ بالملف السابق، ليكون التراجع دقيقتين لا إعادة بناء.
سجّل الآلية وملف المفتاح والاتجاه لكل طرف في ملاحظات النشر، وإلا قرأ الشخص التالي ملفين متشابهين وافترض أن الرقمين يجب أن يتطابقا. الاتجاه تفصيل تنسيقي لا ترقية أمنية: إنه يفصل اتجاهي قناة التحكم ولا يفعل شيئا آخر.