حالت trap در strongSwan: چرا تونل IPsec منتظر ترافیک می‌ماند

هیچ CHILD SA در خروجی وضعیت دیده نمی‌شود، تونل مرده به نظر می‌رسد و سپس یک ping به زیرشبکه دور آن را بالا می‌آورد. در چیدمان IPsec بر اساس تقاضا این توالی خودِ طراحی است، نه خرابی. خط‌مشی trap یک انتخابگر نصب می‌کند و منتظر می‌ماند، و اولین بسته‌ای که با آن مطابقت کند همان چیزی است که IKE و مذاکره CHILD SA را آغاز می‌کند.

بخشی از سردرگمی واژگانی است: «up» برای دو وضعیت متفاوت به کار می‌رود. پیکربندی بارگذاری شده و خط‌مشی هسته وجود دارد، اما انجمن داده وجود ندارد. هر پایشگری که فقط SAهای فعال را بشمارد، یک سایت سالم را تا زمانی که کسی به آن ترافیک نمی‌فرستد، از کارافتاده گزارش می‌کند.

تونل بی‌کار بر اساس تقاضا هیچ CHILD SA برای نشان دادن ندارد

یک مدخل trap به‌خودی‌خود چیزی را احراز هویت نمی‌کند. از هسته می‌خواهد خط‌مشی‌ای برای ترافیک انتخاب‌شده نگه دارد و وقتی بسته‌ای به آن خط‌مشی نیاز دارد، یک acquisition بالا بیاورد. دیمن acquisition را دریافت می‌کند، آن را با تعریف child تطبیق می‌دهد و از همان‌جا مذاکره می‌کند. تا آن لحظه هیچ IKE SA برای نمایش هم وجود ندارد، به همین دلیل هر دو فهرست می‌توانند همزمان خالی باشند.

همین ترتیب است که لاگ‌ها را خوانا می‌کند. ابتدا acquisition می‌آید، سپس IKE_SA_INIT و IKE_AUTH، سپس CHILD SA. اگر لاگ درست پس از acquisition تمام شود، ماشه کار کرده است. مذاکره شکست خورده و پرسش بعدی درباره اعتبارنامه‌ها، پیشنهادها یا دسترس‌پذیری است، نه درباره trap.

با بک‌اند هسته Linux می‌توانید خط‌مشی را پیش از وجود هر SA ببینید. اجرا کنید ip xfrm policy و انتخابگر با جهت out و قالبی که به اتصال اشاره می‌کند را پیدا کنید. آن مدخل همان وضعیت بر اساس تقاضاست و وجودش اولین چیزی است که باید تأیید شود.

start_action تعیین می‌کند آیا اصلاً چیزی منتظر می‌ماند

هر child در 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
    }
}

دو انتخابگر ترافیک تعیین می‌کنند چه چیزی مهم شمرده می‌شود، و بسته‌ای از میزبانی بیرون این پیشوندها trap را فعال نمی‌کند؛ مثل همیشه مسیریابی می‌شود. گسترده‌تر کردن انتخابگرها برای فعال‌تر شدن ماشه، دامنه‌ای را هم که تونل ادعا می‌کند محافظت می‌کند گسترده‌تر می‌کند، پس آنها را از ترافیکی بگیرید که واقعاً می‌خواهید رمزگذاری کنید.

مرجع swanctl.conf مقادیر پذیرفته‌شده را همراه با کنش‌های جداگانه close و DPD که تعیین می‌کنند پس از وجود SA چه رخ می‌دهد، فهرست می‌کند.

بفهمید آیا ماشه اصلاً فعال شده است

شروع کنید با swanctl --list-conns و تأیید کنید child با کنشی که در نظر داشتید بارگذاری شده است. سپس یک بسته از میزبانی درون local_ts به نشانی‌ای درون remote_ts بفرستید و تماشا کنید swanctl --list-sas. اگر خروجی تغییر نکند، هیچ acquisition به دیمن نرسیده است.

دو دلیل معمول برای یک trap خاموش: بسته پیش از رسیدن به خط‌مشی source-NAT شده و دیگر با local_ts مطابقت ندارد، یا اتصال به دلیل خطای نحوی یا اعتبارنامه هرگز بارگذاری نشده است. دوباره اجرا کنید swanctl --load-all و پیش از دست زدن به انتخابگرها خروجی‌اش را بخوانید. اتصالی که بارگذاری نشده هیچ خط‌مشی نصب نمی‌کند، پس چیزی نیست که ترافیک فعالش کند.

جهت هم مهم است: trapی که برای ترافیک خروجی نصب شده با یک بسته ورودی آغاز نمی‌شود. اگر طرف دور باید تونل را بالا بیاورد، به trap خودش نیاز دارد، یا این طرف به start.

انتظار برای اولین بسته همیشه معامله درست نیست

نشست‌های تعاملی هزینه راه‌اندازی را حس می‌کنند. اولین درخواست هزینه تبادل IKE و مذاکره CHILD را می‌پردازد و کلاینتی با مهلت کوتاه می‌تواند پیش از وجود SA تسلیم شود. start پیش‌دستانه آن تأخیر اولین بسته را حذف می‌کند. اما تونلی را برای ترافیکی بالا نگه می‌دارد که ممکن است هرگز نرسد.

سه واقعیت انتخاب را روشن می‌کند: مسیر هر چند وقت استفاده می‌شود، آیا اولین درخواست مهلت تنگ دارد و آیا همتا هنگام بوت در دسترس است. ترافیک دسته‌ای گاه‌به‌گاه و همتایی که ممکن است هنگام بوت آفلاین باشد هر دو به سود trap. کلاینت حساس به تأخیر و همتای همیشه در دسترس به سود start. اگر هر دو طرف بتوانند آغاز کنند، توافق کنید ماشه از کدام است تا مذاکره تکراری نداشته باشید.

خط‌مشی نصب‌شده هم تضمین ضد نشت نیست. اگر الزام fail-closed است، دیوار آتش باید ترافیک بدون SA را بیندازد و آن قاعده بیرون از تعریف child زندگی می‌کند.

سه خطی را ثبت کنید که بحث بعدی را تمام می‌کند

انتخابگرها، کنش راه‌اندازی و خروجی فرمانی را بنویسید که خط‌مشی را بدون SA موجود نشان می‌دهد. آن سه خط دفعه بعد که کسی تونل را از کارافتاده گزارش کند، «بر اساس تقاضا و بی‌کار» را از «بارگذاری نمی‌شود» جدا می‌کند. ثبتشان یک دقیقه وقت می‌برد. بدون آنها همان بررسی از صفر شروع می‌شود.

از میزبانی آزمایش کنید که واقعاً درون انتخابگر است. ping از خود روتر اغلب مسیر دیگری را طی می‌کند و چیزی درباره خط‌مشی محافظت‌کننده از زیرشبکه پشتش ثابت نمی‌کند.