لماذا لا تكون سياسة أمان IPsec مدخلًا في جدول التوجيه

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

ابدأ بالبحث لا بالجدول

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

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

طابِق المحددات على الجانبين

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

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

مطابقة السياسة ليست حالة مثبتة

السياسة المطابقة تقول فقط إن الحزمة يجب أن تُحمى؛ وما زالت النواة تحتاج إلى ارتباط أمان لتنفيذ الحماية. اسردها بـ ip xfrm state، أو بـ swanctl --list-sas عندما يتولى strongSwan التفاوض، واقرأ المحددات والعدادات في كل مدخل.

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

ما لا يزال النفق القائم على المسار يحتاجه

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

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

احسم الملكية قبل تعديل أي شيء

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

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