لماذا يظل نفق IPsec لديك يعمل حتى أول تجديد لمفتاح CHILD SA

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

الاتصال لا يعني توافق إعدادات PFS

مع IKEv2، يُنشأ أول ارتباط فرعي أثناء تبادل المصادقة، وتُشتق مفاتيحه من المواد التي أنتجها ارتباط IKE بالفعل. لا يحدث تبادل Diffie-Hellman منفصل لذلك الارتباط الفرعي، لذا فإن السياسة التي تشترط واحدًا عند التجديد لا تُختبر عند الإنشاء.

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

أين يختفي التعارض في سلسلة المقترح

في strongSwan تُلحق المجموعة بمقترح الارتباط الفرعي، ولهذا تبدو سلسلة مثل aes256gcm16-prfsha256-ecp256 وكأنها اختيار تشفير، لكنها تحمل أيضًا شرطًا لتبادل المفاتيح. القرين الذي لا يقدّم سوى aes256gcm16-prfsha256 لا يحمل هذا الشرط، وتتقاطع القائمتان عند التشفير بينما تختلفان عند التبادل.

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

اقرأ الفشل، لا الملف الذي عدّلته

ابحث عن إشعار notify الذي أنهى التبادل. إعادة توليد مفتاح ارتباط فرعي تعيد «لا مقترح مقبول» تشير إلى قوائم المقترحات؛ وطلب إعادة توليد لا يتلقى ردًا أبدًا يشير إلى المسار أو إلى قرين توقف عن الاستماع. هذان يحتاجان إلى إصلاحين مختلفين، وصياغة سطر السجل تفصل بينهما.

تأكد من الإعدادات الجارية لا من الإعدادات الموجودة على القرص. ملف حُفظ ولم يُحمّل، أو اتصال أُعيدت قراءته من include آخر، سينتج تعارضًا لا يصلحه أي قدر من تعديل الملف المرئي.

ثلاثة أحداث يُطلق عليها جميعًا اسم rekey

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

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

إيقاف التجديد ليس حلًا

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

حاذِ المقترحات بدلًا من ذلك. اختر مجموعة ينفّذها القرينان، وضعها في مقترح الارتباط الفرعي على الطرفين، وأبقِ سياسة التجديد داخل النطاق الذي تحتاجه المؤسسة فعلًا.

أثبته بالتبادل الذي فشل

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

أعِد العمر الطبيعي بعد ذلك واحتفظ بسجلي الحدثين، الفاشل والناجح. الدليل الذي تريده هو أن الاتصال يصمد في دورة حياته، لا أنه صمد أمام ping.