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

يعتمد القرار على أيّ طبقة انتهت صلاحيتها فعليًا.

ثلاث عمليات تُسمّى تدويرًا

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

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

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

ما يلاحظه المستخدمون عند التجديد

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

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

أين تفترق الثلاثة عمليًا

إن كان الشيء الوحيد المنتهي هو مادة المفاتيح، فأعِد تبادل المفاتيح. وإن تغيّر عنوان النظير أو المسار أو ارتباط NAT ولم تعد الحزم تصل، فأعِد الاتصال. وإن كانت المؤسسة تتطلّب تحققًا دوريًا من الهوية، فتلك إعادة مصادقة ولا يغني عنها أي ضبط لمدد الصلاحية.

الإعدادات الافتراضية للبروتوكولات تحمل عادة الجواب الصحيح. يعيد WireGuard تبادل المفاتيح بعد حدّ زمني وحدّ لحجم البيانات دون أي إجراء من المستخدم؛ وتُتفاوَض مدد صلاحية IKEv2 لكل ارتباط فرعي؛ وتُدوّر الأنفاق القائمة على TLS المفاتيح داخل الجلسة القائمة. ورفع مدد الصلاحية لتجنّب خطأ متكرّر يؤجّل الفشل ويطيل التعرّض إذا اختُرِق مفتاح.

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

اختر الإعدادات الافتراضية ثم سجّل المرحلة

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

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

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

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