هل ينبغي تكديس طبقتَي VPN؟ ثلاثة شروط ينبغي فحصها

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

سجّل ما يحتفظ به المراقب

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

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

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

الشرط الأول: هل تتوقف الطبقتان في مكانين مختلفين؟

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

افحص ذلك بالحالة المثبتة لا بالتصميم. على Linux، تسرد ip xfrm state كل ارتباط أمني ونقاط نهايته، وهذا يحسم أين تتوقف كل طبقة فعليًا.

الشرط الثاني: هل مادة المفاتيح مستقلة فعلًا؟

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

هنا يتفوق إنشاء المفاتيح الهجين على تكديس الأنفاق. يستطيع IKEv2 حمل عدة تبادلات مفاتيح في تفاوض واحد، فيستطيع زوج كلاسيكي وKEM بعد-كمي أن يغذيا مفاتيح الجلسة نفسها بدل أن يُلفّ أحدهما حول الآخر. النتيجة ارتباط أمني واحد تعتمد مفاتيحه على السرّين معًا، وعلى المهاجم أن يكسر الاثنين. هذا بناء موثق بتكوين محدد، وليس كذلك تكديس مصنوع يدويًا لمنتجَي VPN. على strongSwan، تطبع swanctl --list-sas الاقتراح المتفاوض عليه لكل SA، وهكذا تتحقق مما جرى فعلًا لا مما أعددته.

الشرط الثالث: هل تعيش البيانات أطول من الافتراض الخارجي؟

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

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

ما الذي تبنيه بدلًا من ذلك حين يكون الجواب لا

إن فشل أي من الشروط الثلاثة، فاترك التعشيش وأنفق الجهد على الطبقة التي تحمل متطلب العمر فعلًا. أعدّ تبادل مفاتيح هجينًا في البروتوكول الذي تشغله أصلًا، وأبقِ التنفيذ محدثًا، واكتب التكوين الذي تعتمد عليه. ذكر ML-KEM في وثيقة تصميم ليس خاصية أمنية، ووثيقة FIPS 203 تعرّف آلية تغليف المفاتيح، لا نفقك.

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

قبل نافذة التغيير، التقط جدول SA الحالي والاقتراحات المتفاوض عليها، وبعدها التقطها مرة أخرى وقارن، لأن الدليل الوحيد المهم هو ما وافقت عليه الأجهزة فعلًا.