IPsec در IPsec: تونل بیرونی باید کدام آدرس‌ها را حمل کند

IPsec تودرتو وقتی دو لایه روی ماشین‌های مختلف پایان می‌یابند، راحت‌تر قابل استدلال است. چهار دروازه، دو تونل و یک پرسش که تعیین می‌کند طراحی کار می‌کند یا نه: تونل بیرونی وقتی تونل داخلی کار بسته را تمام کرد، واقعاً چه می‌بیند؟ به آن پاسخ دهید و انتخابگرها، مسیرها و ترتیب عیب‌یابی از پی می‌آیند. اشتباه کنید و یک روز را صرف اشکال‌زدایی تونلی می‌کنید که فنی بالاست.

مدل چهار دروازه

دروازه‌های بیرونی A و B اولین تونل را میان دو سایت می‌سازند. پشت A دروازه داخلی C با آدرس گذر 10.60.0.2 و پشت B دروازه داخلی D با آدرس گذر 10.70.0.2 قرار دارد. شبکه‌های برنامه پشت C و D هستند و هر آدرس در مثال عمداً هم‌پوشانی ندارد.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

تقسیم لایه‌ها میان چهار میزبان یعنی هر ماشین یک مرز را اعمال می‌کند. یک میزبان واحد که هر دو لایه را اجرا می‌کند باید دو مجموعه سیاست، دو جدول مسیریابی و دو حالت خرابی را روی یک ماشین هماهنگ کند، کاری ممکن اما بسیار سخت‌تر برای مشاهده.

هر لایه فقط محافظت خودش را برمی‌دارد

C یک بسته برنامه را برای D رمز می‌کند. نتیجه از C به D آدرس‌دهی می‌شود و همان چیزی است که به A می‌رسد. همه‌چیز در پایین‌دست به این بازنویسی بستگی دارد.

A آن را دوباره برای B رمز می‌کند. B لایه بیرونی را رمزگشایی می‌کند، بسته‌ای از C به D می‌بیند و آن را همچنان رمزشده ارسال می‌کند. D محافظت داخلی را برمی‌دارد و بسته برنامه را تحویل می‌دهد.

پس A و B نقاط پایانی داخلی و فراداده‌هایشان را می‌بینند، اما طرفی نیستند که بار برنامه را رمزگشایی می‌کند. این ویژگی واقعی طراحی است و ادعای اینکه C، D یا میزبان‌های برنامه قابل‌اعتمادند نیست.

انتخابگرهای بیرونی دروازه‌های داخلی را نام می‌برند

اینجاست که بیشتر این ساخت‌وسازها شکست می‌خورند. برای یک تونل بیرونی مبتنی بر سیاست، انتخابگرهایی که مذاکره می‌کنید باید آدرس‌هایی را داشته باشند که A و B واقعاً با آن‌ها کار می‌کنند: 10.60.0.2/32 و 10.70.0.2/32، به ترتیب درست محلی و راه دور.

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

مجوز بیرونی را هم به UDP 500 محدود نکنید. اتصال داخلی مسیر داده خودش را دارد که بسته به آنچه مذاکره کرده از ESP یا کپسوله‌سازی UDP استفاده می‌کند و سیاست بیرونی باید آن پروتکل را مجاز کند.

نتیجه را با swanctl --list-sas روی هر دروازه بررسی کنید و تأیید کنید که انجمن‌های امنیتی فرزند آدرس‌هایی را گزارش می‌کنند که در نظر داشتید، نه آن‌هایی که فرض کردید. اگر فهرست زیرشبکه‌های برنامه را نشان می‌دهد، سیاست بیرونی برای لایه اشتباه نوشته شده است. پیش از اشکال‌زدایی مسیریابی، انتخابگرها را اصلاح کنید، چون مسیریابی درست به نظر می‌رسد و شمارنده‌ها تکان نمی‌خورند.

ارسال و تله بازگشت

انتخابگرها جای مسیریابی را نمی‌گیرند. A و B باید ترافیک میان C و D را در هر دو جهت ارسال کنند، یعنی فعال بودن ارسال IP، مسیرهایی که به تونل اشاره می‌کنند و مسیر بازگشتی که در طرف دیگر وجود دارد.

اگر تونل بیرونی از رابط‌های XFRM استفاده می‌کند، مسیرها رابط را انتخاب می‌کنند در حالی که سیاست‌های مذاکره‌شده هنوز محدود می‌کنند که چه چیزی حمل می‌شود. رابط چیزی را که محافظت می‌شود گسترش نمی‌دهد؛ فقط نحوه برداشتن بسته توسط هسته را تغییر می‌دهد.

تله بازگشت است. مسیر A به نقطه پایانی بیرونی B باید از شبکه زیرین پیروی کند، نه از تونلی که A می‌سازد، وگرنه کپسوله‌سازی می‌کوشد درون خودش سفر کند و اتصال هرگز کامل نمی‌شود.

پیش از افزودن لایه‌ها، ترجمه را بررسی کنید

پیش از تنظیم هر چیز دیگر، هر NAT مبدأ روی A و B را ببینید. قاعده‌ای که آدرس C را پیش از اعمال سیاست IPsec بازنویسی می‌کند می‌تواند انتخابگرهای موردتوافق را بشکند و همچنین می‌تواند تغییر دهد D در طرف دیگر چه دریافت می‌کند.

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

اگر قاعده NAT واقعاً لازم است، بنویسید هر طرف فکر می‌کند با کدام آدرس صحبت می‌کند. همان یک خط بیشتر بحث‌ها را درباره اینکه تونل مقصر است یا ترجمه حل می‌کند. همچنین به مهندس بعدی می‌گوید یک سال بعد که قاعده حذف شد کجا را ببیند. Ping هیچ‌یک از این کارها را نمی‌کند.

fail-closed را اثبات کنید و MTU را بررسی کنید

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

سه حالت را آزمایش کنید: تونل بیرونی پایین، تونل داخلی پایین و بازیابی پس از بازگشت هر دو. از شمارنده‌های سیاست در هر دروازه استفاده کنید، چون دو نشست IKE برقرار فقط ثابت می‌کند که مذاکره صفحه کنترل موفق بوده است.

برای هر دو کپسوله‌سازی بودجه در نظر بگیرید. IKE کارکننده نتیجه بسته‌های کوچک است و بسته‌های برنامه با اندازه کامل ممکن است پس از افزودن دو سرآیند باز هم شکست بخورند؛ با اندازه بار مشخص روی مسیر واقعی آزمایش کنید نه اینکه فرض کنید اعداد جمع می‌شوند. حساب ساده است، مسیر نه.