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

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

النفق الخامل قيد الطلب ليس لديه CHILD SA ليعرضه

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

هذا الترتيب هو ما يجعل السجلات مقروءة. تأتي عملية الاكتساب أولًا، ثم IKE_SA_INIT وIKE_AUTH، ثم CHILD SA. إذا انتهى السجل مباشرة بعد الاكتساب، فقد نجح المشغّل. فشل التفاوض، والسؤال التالي يدور حول بيانات الاعتماد أو المقترحات أو قابلية الوصول، لا حول المصيدة.

مع خلفية نواة Linux يمكنك رؤية السياسة قبل وجود أي SA. شغّل ip xfrm policy وابحث عن المحدِّد باتجاه out وقالب يشير إلى الاتصال. ذلك المدخل هو الحالة قيد الطلب، ووجوده هو أول ما يجب تأكيده.

start_action يقرر ما إذا كان أي شيء سينتظر أصلًا

كل ابن في swanctl.conf يحمل start_action. start يبدأ عند تحميل الإعداد، trap يثبّت السياسة وينتظر، أما none يترك البدء لشيء آخر. فقط trap ينتج سلوك «ping فيصعد» الموصوف أعلاه.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

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

إن مرجع swanctl.conf يسرد القيم المقبولة، إلى جانب إجراءي close وDPD المنفصلين اللذين يحكمان ما يحدث بعد وجود SA.

اكتشف ما إذا كان المشغّل قد عمل أصلًا

ابدأ بـ swanctl --list-conns وتأكد من تحميل الابن بالإجراء الذي أردته. ثم أرسل حزمة واحدة من مضيف داخل local_ts إلى عنوان داخل remote_ts وراقب swanctl --list-sas. إذا لم تتغير المخرجات، فلم يصل أي اكتساب إلى الخادم.

سببان عاديان لمصيدة صامتة: أن تكون الحزمة قد خضعت لـ NAT مصدري قبل أن تصطدم بالسياسة ولم تعد تطابق local_ts، أو أن الاتصال لم يُحمَّل أصلًا بسبب خطأ نحوي أو خطأ في بيانات الاعتماد. أعد تشغيل swanctl --load-all واقرأ مخرجاته قبل لمس المحدِّدات. الاتصال الذي فشل تحميله لا يثبّت سياسة، فليس هناك ما تُطلقه حركة المرور.

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

انتظار أول حزمة ليس دائمًا المقايضة الصحيحة

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

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

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

سجّل الأسطر الثلاثة التي تنهي الجدال التالي

اكتب المحدِّدات وإجراء بدء التشغيل ومخرجات الأمر التي تُظهر وجود السياسة دون SA. تلك الأسطر الثلاثة تفصل «قيد الطلب وخامل» عن «لا يُحمَّل» في المرة التالية التي يبلغ فيها أحد عن النفق كمعطّل. تكلف دقيقة لتسجيلها. وبدونها تبدأ نفس التحقيقات من الصفر.

اختبر من مضيف داخل المحدِّد فعلًا. الـ ping من الراوتر نفسه غالبًا يسلك مسارًا مختلفًا ولا يثبت شيئًا عن السياسة التي تحمي الشبكة الفرعية خلفه.

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