يبدأ IKE، ويعلن الطرفان دعم AES، ومع ذلك يفشل النفق برسالة NO_PROPOSAL_CHOSEN. يسجّل السجل اسم الاقتراح لكنه لا يذكر الحقل الذي لم يتطابق. الاقتراح عرض كامل، وأي حقل غير متوافق يُبطل التركيبة بأكملها وليس ذلك السطر فقط. وقراءته كمجموعة من اختيارات الخوارزميات المستقلة هي السبب المعتاد في بقاء عدم التطابق غير مرئي.

مفاوضتان بقائمتَي اقتراح منفصلتين

يبني IKEv2 رابطتَي أمان. الأولى هي IKE SA، وهي تحمي تبادل التحكم نفسه، والثانية هي CHILD SA، وهي تنقل حركة المرور لديك عبر ESP. ولكل منهما قائمة اقتراح خاصة، ويمكن للنظير أن يقبل إحداهما ويرفض الأخرى.

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

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

أي الحقول تنتمي إلى أي اقتراح

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

FieldIKE SA proposalCHILD SA proposal
EncryptionRequiredRequired
IntegrityRequired unless AEADRequired unless AEAD
PRFRequiredNot present
DH groupRequiredOnly for PFS
ESNNot presentOptional

يسمّي حقل التشفير الخوارزمية، وفي معظم الصياغات طول المفتاح. ويسمّي حقل السلامة التجزئة المستخدمة لمصادقة النص المشفَّر، ويسمّي PRF الدالة التي تشتق مادة المفتاح لـ IKE SA. وتُنشئ مجموعة DH مادة سرية مشتركة جديدة، ولهذا تظهر في الجانبين لكن لأغراض مختلفة.

أرقام التسلسل الممتدة تنتمي إلى مسار البيانات فقط. وهي توسّع فضاء التسلسل وتُتفاوض كجزء من اقتراح CHILD، لذا فإن أي عدم تطابق هناك يرفض عرض CHILD ويترك IKE SA دون مساس.

كيف يُختار عرض كامل واحد

كل اقتراح مجموعة، ويبحث المستجيب عن مجموعة يكون فيها كل حقل مطلوب مقبولًا. ويمكن لقائمتين أن تحتويا على AES وSHA-256 ومع ذلك ألا تحتويا على إدخال متوافق، لأن طول المفتاح أو PRF أو مجموعة DH يختلف. وتجري المقارنة لكل اقتراح، لا لكل خوارزمية.

عندما لا يتطابق شيء، يرسل المستجيب NO_PROPOSAL_CHOSEN مع نوع SA الذي فشل. اقرأ أي قائمة اقتراح يشير إليها الإشعار قبل تعديل الإعداد؛ فتغيير خوارزميات ESP بينما رُفض اقتراح IKE يهدر دورة تصحيح.

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

AEAD يحذف حقلًا بدلًا من أن يضيف واحدًا

يصادق AES-GCM وChaCha20-Poly1305 ويشفّران في عملية واحدة. وعند اختيار أي منهما لـ ESP، لا تُتفاوض خوارزمية السلامة بشكل منفصل، لأن بناء AEAD يغطيها بالفعل. لذا فإن اقتراحًا يقرن AES-GCM بـ SHA-256 يكون زائدًا في أفضل الأحوال ومرفوضًا في أسوئها.

يبقى PRF منفصلًا في جانب IKE، لأنه يشتق مفاتيح قناة التحكم بدلًا من حماية الحمولات. ولهذا يمكن لاقتراح IKE أن يجمع بشكل مشروع بين خوارزمية AEAD وPRF ومجموعة DH، بينما يسرد اقتراح ESP المطابق خوارزمية AEAD فقط ومجموعة PFS الاختيارية.

طول المفتاح جزء من رمز التشفير، لذا فإن AES-128-GCM وAES-256-GCM عرضان مختلفان. وملف تعريف منسوخ من دليل يفترض مفاتيح 256-bit لن يتطابق مع نقطة نهاية مهيّأة لمفاتيح 128-bit، حتى لو قال السطران AES-GCM. ويمكن للنظيرين أن يتفقا على عائلة الخوارزمية ومع ذلك يرفض كل منهما الآخر بسبب الرقم بعد الشرطة.

اقرأ SA المثبّتة، لا الإعداد

قائمة الاقتراحات المهيّأة هي عرض؛ وSA المثبّتة هي النتيجة. على strongSwan ونواة Linux، يتوفر العرضان معًا:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas يطبع الخوارزميات المتفاوض عليها لكل SA، بما في ذلك ما إذا كان CHILD يستخدم AEAD. ip xfrm state يُظهر ما ثبّته النواة فعليًا ، وهو المكان الذي يؤكّد أن إعادة توليد المفاتيح لم تنحدر إلى حزمة مختلفة عن التي وثّقتها.

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

مقالات ذات صلة