أي حزم OpenVPN يحميها ملخّص auth؟
خيار auth يغطي أقل مما يوحي به الملف الشخصي. تناوَل القناة وحالة AEAD وحماية قناة التحكم قبل أن تضبط سياسة الملخّص.
معظم الجدل حول ملخّصات OpenVPN يبدأ من الحزمة الخاطئة. إن قراءة auth SHA256 على أنها «لا تقبل إلا الأقران الذين يقدمون SHA256» هي أول ما يجب نسيانه. يسمّي الخيار ملخّصًا لحزم معيّنة، وأي الحزم تكون كذلك يعتمد على القناة وعلى ما إذا كانت تلك القناة AEAD. اعمل على الأسئلة الأربعة أدناه بالترتيب؛ كل سؤال يضيّق ما يمكن أن يعنيه الإعداد في نشرك.
سمِّ القناة التي يُفترض أن يحميها الإعداد
OpenVPN لديه قناة تحكم تحمل حركة مصافحة TLS وقناة بيانات تحمل حِمل النفق. لملخّص auth دور في الاثنتين، لكن ليس الدور نفسه، والملف الشخصي نادرًا ما يجعل الفرق مرئيًا. اكتب أي الاثنتين تحاول تقييده قبل أن تمسّ ملف إعداد.
الجدول أدناه هو النسخة المختصرة لكيفية وقوع الخيار نفسه في كل سياق.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
تحقق مما إذا كانت قناة البيانات AEAD قبل أن تعتمد عليها
إذا كانت شيفرة البيانات المتفاوض عليها AES-GCM أو CHACHA20-POLY1305، فإن قناة البيانات تصادق نفسها ولا يؤدي الملخّص المنفصل العمل الذي قد تتخيله. كلاهما بنى AEAD، لذا تُنتَج السلامة بالعملية نفسها التي تشفّر الحِمل. هذا ليس تخفيضًا، لكنه يعني أن سياسة يُبرَّر بها «كل حزمة بيانات هي HMAC-SHA256» خاطئة واقعيًا على ذلك النفق. أكّد القيمة المتفاوض عليها في سجل الخادم أو مخرجات حالة العميل قبل أن تعيد كتابة السياسة.
افحص الشيفرة التي فُوِّضت فعليًا بدلًا من القائمة في الملف الشخصي، لأن التفاوض قد يهبط على عضو آخر من المجموعة. data-ciphers AES-256-GCM:AES-128-GCM قائمة تفاوض، وكلتا المدخلتين AEAD، فلا واحدة منهما تستهلك ملخّص auth لحماية الحِمل.
اعتبر حماية قناة التحكم قرارًا مستقلًا
يضيف tls-auth HMAC إلى حزم قناة التحكم ويأخذ ملخّصه من إعداد auth، ولهذا يمكن أن يكون لنفق AEAD ملخّص ذو معنى مُعدّ. أما tls-crypt فترتيب مختلف بحماية ثابتة خاصة به، فلا تفترض أنه يرث كل خصائص tls-auth. اقرأ الوثائق للآلية التي اخترتها بدلًا من نقل الافتراضات بينهما.
يجب أن يتفق الطرفان أيضًا على الترتيب وعلى اتجاه المفتاح. ملخّص متطابق مع ملف مفتاح مستخدم في الاتجاه الخطأ ينتج مصافحة تفشل لأسباب لا يستطيع إعداد الملخّص تفسيرها.
أبقِ auth منفصلًا عن تفاوض الشيفرة والشهادات
ثلاثة إعدادات تُخلط باستمرار: ملخّص auth وقائمة شيفرات البيانات وخوارزمية توقيع الشهادة. تغيير الأول لا يعيد إصدار شهادة، ولا يختار ملخّص توقيعها، ولا ينشئ طريقة كلمة مرور المستخدم. تعريفات خيارات البروتوكول في مصادر OpenVPN 2.6 تصف كلًا منها في قسمه الخاص، وهو تذكير مفيد بأنها مفاتيح مستقلة.
عندما يرفض قرين الاتصال بعد تغيير الملخّص، يكون السبب عادة عدم تطابق في أحد الإعدادين الآخرين. اقرأ الطرفين قبل أن تغيّر أيًا منهما.
اكتب السياسة وطابقها مع الإعدادات العاملة
ينبغي أن يذكر بيان على مستوى الأسطول أنماط قناة البيانات المسموح بها وحماية قناة التحكم المختارة صراحةً، في الجملة نفسها. تلك الجملة قابلة للاختبار؛ أما «نستخدم SHA256» فليست كذلك. ثم طابقها مع ملفات تعريف الخادم والعميل الفعّالة لا مع قالب في مستودع.
اختم بتسجيل ما فاوضه كل نفق فعليًا وأي آلية صادقت حزمه. سطر auth المرئي في ملف تعريف دليل على نية الإعداد فقط، والنية هي أرخص جزء من الفحص.