strongSwan پس از راه‌اندازی مجدد peer پایین می‌ماند: بازیابی یک تونل

دروازه دور راه‌اندازی مجدد می‌شود، ظرف یک دقیقه برمی‌گردد، و daemon محلی strongSwan همچنان کار می‌کند در حالی که تونل پایین است. یک کار cron که ESTABLISHED را grep می‌کند و daemon را دوباره راه می‌اندازد، در نهایت روی آن را می‌پوشاند، و همچنین هر تونل بی‌ربط روی ماشین را قطع می‌کند و شاید همان تونلی را که شکست خورده از دست بدهد. بازیابی متعلق به اتصالی است که باید برگردد و در تنظیماتی بیان می‌شود که از reload جان سالم به در می‌برند. این runbook آن را برای یک اتصال آماده می‌کند و نتیجه را با نام ثابت می‌کند.

راه‌اندازی مجدد سراسری را کنار بگذارید، شواهدش را نگه دارید

راه‌اندازی مجدد daemon دو نقص مشخص دارد: وضعیت هر اتصال را نابود می‌کند، و چیزی درباره این که واقعاً کدام رویداد شکست خورده به شما نمی‌گوید. متنی که grep کردید ممکن است از اتصال دیگری آمده باشد، در حالی که child مورد نیاز بی‌کار مانده بود چون هیچ چیز آن را فعال نکرد.

پیش از تغییر هر چیزی اتصال‌های بارگذاری‌شده و انجمن‌های فعال را بخوانید تا تصویری از «قبل» داشته باشید و پس از بازگشت peer مقایسه کنید.

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 به‌محض مرده اعلام شدن peer مذاکره تازه می‌خواهد، و keyingtries=0 در سطح اتصال تلاش‌های بیشتر تا موفقیت یا خطای دائمی را مجاز می‌کند. در IKEv2 مقدار dpd_timeout هیچ اثری ندارد، چون بازفرست عادی تعیین می‌کند چه زمانی peer پاسخ نمی‌دهد.

تأخیر در آن نمونه یک نقطه شروع است نه یک مهلت جهانی. آن را بر اساس مدت راه‌اندازی مجدد peer و میزان بازفرستی که حاضرید تحمل کنید انتخاب کنید.

بدانید از کدام رویداد بازیابی می‌کنید

سه خرابی روی داشبورد یکسان به نظر می‌رسند و تنظیمات متفاوتی می‌خواهند. اتصال اولیه‌ای که هرگز بالا نیامد مسئله پیکربندی یا دسترس‌پذیری است. peer که پاسخ دادن را متوقف کرد همان مورد DPD است. child که peer صریحاً بست یک رویداد سیاستی با close_action خودش است که DPD هرگز آن را نمی‌بیند. خواندن گزارش پیرامون قطعی به شما می‌گوید کدام یک از سه مورد را دارید، و پاسخ، راه‌حل را تغییر می‌دهد.

به اتصالی که اپراتورها آگاهانه برای نگهداری می‌بندند آغاز مجدد تهاجمی اضافه نکنید، وگرنه تونل در میانه پنجره دوباره ظاهر می‌شود. برای طرح‌های بر اساس تقاضا یک trap نگه‌داشته‌شده کافی است، چون ترافیک منطبق child را بدون هیچ تایمری دوباره برپا می‌کند.

با نام بررسی کنید، نه با وضعیت daemon

در حالی که peer هنوز پایین است اتصال و child آن را با نام بخوانید، و سپس بار دیگر وقتی برگشت؛ تفاوت میان این دو خروجی همان شاهد است.

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

سپس سرویس را تأیید کنید نه انجمن را. یک انجمن امنیتی تازه برای child به‌همراه درخواست موفق به مقصد خصوصی پشت آن، همان جفت واقعیتی است که اهمیت دارد، و daemon در حال اجرا با یک تونل بی‌ربط سالم هیچ‌کدام را ثابت نمی‌کند.

اگر child هرگز آغاز نمی‌شود، بررسی کنید که ترافیک آزمایشی دقیقاً با انتخابگرهای پیکربندی‌شده مطابقت دارد، از جمله پروتکل و درگاه. اگر آغاز شد و شکست خورد، خطای احراز هویت یا پیشنهاد را بخوانید به‌جای پنهان کردنش پشت یک حلقه بی‌پایان، چون keyingtries=0 با خوشحالی یک رد دائمی را تا ابد تکرار می‌کند.

تغییر را در یک پنجره بارگذاری کنید و دوباره آزمایش کنید

reload امن‌تر از راه‌اندازی مجدد daemon است، و با این حال رایگان نیست: جایگزینی یا تخلیه یک child می‌تواند انجمنی آغازشده را ببندد یا trap آن را بیندازد.

در یک پنجره نگهداری بارگذاری کنید، فایل پیشین را نگه دارید، و تأیید کنید که اتصال با تنظیمات مورد نظر شما ظاهر می‌شود نه با پیش‌فرض‌ها.

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

با بازگرداندن فایل پیشین و بارگذاری دوباره آن عقب‌نشینی کنید، سپس همان دو فرمان را تکرار کنید. تونلی که فقط پس از راه‌اندازی مجدد daemon برمی‌گردد تعمیر نشده، بازنشانی شده است.