كيف يعمل IPsec القائم على المسارات مع واجهة XFRM
تمنح واجهة XFRM بروتوكول IPsec القائم على المسارات جهازًا للتوجيه عبره. يجب أن يتوافق if_id واقترانات الأمان الموجودة خلفه والمسار الخارجي جميعًا.
يسلّم IPsec القائم على المسارات جدول التوجيه قرارًا كان محددو السياسات يتخذونه سابقًا. في لينكس، القطعة التي تجعل ذلك ممكنًا هي واجهة XFRM: جهاز افتراضي تُطابَق حركته بحالة IPsec عبر معرّف واجهة لا عبر محدد. إنشاء واحدة يتطلب أمرًا واحدًا ولا يثبت شيئًا عن وجود نفق. الجهاز هو وصلة بين التوجيه وسياسة الأمان، ويجب تهيئة طرفي تلك الوصلة قبل حماية أي شيء.
ما هو الجهاز وما ليس هو
واجهة XFRM هي مقبض توجيه. تُطابَق الحزم الموجّهة إليها مع سياسات XFRM التي تشير إلى معرّف الواجهة نفسه، وإذا وُجدت سياسة وحالة معًا جرى تغليفهما. ومن دون ذلك تظل الواجهة موجودة، وتبقى العدادات ساكنة، ويذهب الترافيك إلى مكان غير مفيد.
هذا هو أول انقسام تشخيصي. المسار إلى الجهاز حقيقة توجيهية، أما الحالة المثبَّتة فهي حقيقة أمنية، والعداد الصاعد على الجهاز ليس أيًا منهما. عندما يقول الناس إن النفق قائم لأن الواجهة تُظهر UP، فإنهم يصفون أعلام الوصلة لجهاز افتراضي لا نظير له. العلم يعني أن الجهاز أُنشئ وفُعّل، ولا شيء أكثر.
حدود أخرى: معرّف الواجهة ليس اسمًا. جهازان بأسماء متشابهة ومعرّفات مختلفة لا يتشاركان الحالة، والاتصال المهيأ بمعرّف خاطئ يثبّت حالة لن يستخدمها أي مسار أبدًا.
ابنِ واحدة بالترتيب الصحيح
ابدأ بالجهاز الخارجي وبرقم ستضعه أيضًا في تهيئة الخفي. يستخدم المثال eth0 كواجهة خارجية و42 كمعرّف، وهي عناوين ينبغي أن تستبدلها بعناوينك.
ارفع الجهاز، ثم أكّد المعرّف الذي سجّله النواة قبل لمس تهيئة VPN:
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'الآن هيئ الاتصال في strongSwan بالمعرّف نفسه، إذ يجب على الخفي تثبيت سياسات وحالات تشير إليه. اضبط محددي الترافيك المحلي والبعيد على النطاق الذي تنوي توجيهه، ثم وجّه ذلك النطاق إلى الجهاز. يجب أن تتفق تهيئة الخفي وجدول التوجيه على المعرّف والوجهات معًا، ولا يوفّر أحدهما الآخر.
أبقِ IKE وESP خارج مسار النفق
المسار الافتراضي الموجّه إلى جهاز XFRM يلتقط الحزم المغلَّفة إضافة إلى الترافيك الذي تحمله. النتيجة حلقة: تحاول البوابة إرسال ESP الخاص بها عبر النفق الذي يُفترض أن يبنيه ESP نفسه.
الحل هو مسار أكثر تحديدًا لعنوان النظير الخارجي عبر الواجهة الفيزيائية، وهو يتغلب على الافتراضي لأنه يطابق بتات أكثر. التوجيه القائم على العلامات يؤدي المهمة نفسها عندما تتشارك أنفاق عدة جدولًا واحدًا، ويوثّق strongSwan المقاربتين لعمليات النشر القائمة على المسارات.
أيًا كان ما تختاره، تحقق من أن الحزمة الخارجية تغادر دون تغليف. الفحص السريع هو تنفيذ ping على عنوان النظير الخارجي بعد قيام النفق؛ فإن فشل ذلك والواجهة قائمة، فاشتبه في الالتقاط لا في الوصولية. ينطبق المنطق نفسه على منفذ IKE، لأن ترافيك UDP الخاص بالخفي يجب ألا يُوجَّه إلى الجهاز الذي يحاول إقامته.
افحص العدادات في مكانين قبل لوم التشفير
عدادات الواجهة وعدادات الحالة تقيس مراحل مختلفة. الحزم الموجّهة إلى الجهاز تزيد عداده حتى عندما لا تطابق أي حالة، أما عدادات الحالة فلا تتحرك إلا للترافيك الذي غُلِّف فعليًا.
اقرأ كليهما، ثم اقرأ رؤية الخفي لاقتران الابن:
ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sasارتفاع عدادات الجهاز مع خروج حالة فارغة يعني أن التوجيه يعمل والسياسة لا تطابق، وهو عادة خطأ في المعرّف أو المحدد. ارتفاع عدادات الحالة مع عدم إبلاغ الجانب البعيد بشيء يعني أن الحزم تغادر لكنها لا تصل أو تفشل في المصادقة، ما يشير إلى المسار أو تهيئة النظير. اقتران مُدرج بلا ترافيك هو مشكلة محدد في أحد الطرفين، وليس شيفرة معطوبة.
قرّر من يثبّت المسارات
مالكان لجدول توجيه واحد هو المصدر المعتاد للتذبذب. إذا ثبّت الخفي المسارات تلقائيًا، فلا يجوز لمدير الشبكة لديك أن يثبّت أيضًا مسارًا افتراضيًا عبر الجهاز نفسه، والمسار اليدوي الذي يضيفه سكربت الإقلاع سيُزال في المرة التالية التي يعيد فيها الخفي التهيئة.
اختر مالكًا واحدًا واكتب ذلك. عندما يملك الخفي المسارات، أبقِ سكربت الإقلاع خارج الجدول ودع تعريف الاتصال يصف محددات الترافيك. وعندما يملكها مدير الشبكة، عطّل التثبيت التلقائي واقبل أن الخفي لن يصلح مسارًا مفقودًا عند إعادة الاتصال.
قواعد التمرير والجدار الناري قرار منفصل فوق ذلك، لأن البوابة التي تمرر ترافيك مضيفين آخرين تحتاج إلى الاثنين. يجعل IPsec القائم على المسارات ذلك الترافيك سهل التعبير بأدوات توجيه عادية؛ لكنه لا يجعل طبقة السياسة اختيارية.