strongSwan يبقى متوقفًا بعد إعادة تشغيل النظير: استعادة نفق واحد

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

استغنِ عن إعادة التشغيل الشاملة واحتفظ بأدلتها

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

اقرأ الاتصالات المحمّلة والارتباطات النشطة قبل تغيير أي شيء، حتى تملك صورة قبلية تقارن بها بعد عودة النظير.

swanctl --list-conns
swanctl --list-sas

ضع البدء وإعادة المحاولات على الاتصال العائد

في نشر swanctl.conf تعيش هذه الإعدادات على مستوى الاتصال والـchild لا في سياسة عامة. والمقتطف أدناه مثال من جهة البادئ يفترض أن المقترحات والمصادقة والمحددات صحيحة أصلًا.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

يقرر start_action ما يحدث عند تحميل الـchild: يبدأ start فورًا، بينما يثبّت trap سياسة تطلق البدء عند ظهور حركة مطابقة. كتابة trap|start تتطلب strongSwan 5.9.6 أو أحدث، لذا تحقق من الإصدار قبل نسخ السطر. يطلب dpd_action=restart مفاوضة جديدة بمجرد إعلان موت النظير، ويسمح keyingtries=0 على مستوى الاتصال بمزيد من المحاولات حتى النجاح أو خطأ دائم. تحت IKEv2 لا يكون لـdpd_timeout أي تأثير على الإطلاق، لأن إعادة الإرسال العادية هي التي تقرر متى لا يستجيب النظير.

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

اعرف من أي حدث تستعيد

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

لا تضف إعادة بدء عدوانية إلى اتصال يغلقه المشغلون عمدًا للصيانة، وإلا ظهر النفق مجددًا في منتصف النافذة. في تصاميم الطلب عند الحاجة يكفي trap محتفظ به، لأن الحركة المطابقة تعيد إنشاء الـchild دون أي مؤقت.

تحقق بالاسم لا بحالة الدايمون

اقرأ الاتصال وchild الخاص به بالاسم بينما النظير ما زال متوقفًا، ثم مرة أخرى بعد عودته؛ والفرق بين هذين الخرجين هو الدليل.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

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

إن لم يبدأ الـchild أبدًا، تحقق من أن حركة الاختبار تطابق المحددات المهيأة بدقة، بما في ذلك البروتوكول والمنفذ. وإن بدأ وفشل، فاقرأ خطأ المصادقة أو المقترح بدلًا من إخفائه خلف حلقة لا تنتهي، لأن keyingtries=0 سيكرر رفضًا دائمًا إلى الأبد.

حمّل التغيير في نافذة صيانة وأعد الاختبار

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

حمّل أثناء نافذة صيانة، واحتفظ بالملف السابق، وتأكد من أن الاتصال يظهر بالإعدادات التي قصدتها لا بالإعدادات الافتراضية.

swanctl --load-conns
swanctl --list-conns

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