شفرات Windows وstrongSwan: طابق الطبقة الصحيحة

كلا الطرفين يعلن AES-128 والنفق ما زال يرفض أن يُبنى. إن CBC وGCM تحويلان مختلفان يصادف أنهما يتشاركان طول المفتاح نفسه، والعميل الذي يعرض أحدهما لا يُرضي بوابة لا تقبل إلا الآخر. كلمة AES تصف عائلة، لا اتفاقًا.

هناك محور ثانٍ أيضًا، وهو المحور الذي ينتج الأخطاء المربكة.

طبقتان، قائمتان مستقلتان

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

النتيجة العملية هي أنه يمكن أن تكون لديك سياسة تبادل مفاتيح مقبولة تمامًا وسياسة قناة بيانات لا يقبلها النظير. قائمة تتفاوض؛ والأخرى تحمي الحزم. وتغيير قيمة في الأولى لا يؤثر على الثانية، مهما تشابهت الاثنتان في مربع حوار التهيئة.

اكتب القائمتين قبل أن تقارنهما بالبوابة. فالمقارنة من الذاكرة هي الطريقة التي يُحرَّر بها حقل مرتين ولا يُحرَّر الآخر أبدًا. أبقِ وحدة تحكم البوابة مفتوحة بجانب الملف الشخصي.

اقرأ الخطأ بجانب المقترحات

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

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

أبقِ CBC وGCM بديلين منفصلين

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

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

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

مقترح ESP ليس مقترح IKE باسم آخر

رمز التشفير يبدو متطابقًا في القائمتين، ولا يكاد شيء آخر ينتقل. فمقترح ESP ليس فيه دالة شبه عشوائية لتبادل المفاتيح، ومتطلبات التكامل والسرية الأمامية فيه تُحتج بها مقابل سياسة Windows على الطرف الآخر بدلًا من نسخها من سطر IKE. وترجمة قائمة إلى الأخرى آليًا تنتج شيئًا يتحقق ولا يتفاوض أبدًا.

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

تحقق من المجموعتين، ثم من إعادة توليد المفتاح

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

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