چرا یک سیاست امنیتی IPsec ورودی جدول مسیریابی نیست

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

با جست‌وجو شروع کنید، نه با جدول

از هسته بپرسید واقعاً چه می‌کند: ip route get 10.20.0.5 مسیر انتخاب‌شده، رابط خروجی و نشانی مبدأیی را که استفاده می‌کند چاپ می‌کند. یک پیشوند، یک قاعده سیاست، یک نشانه یا یک مبدأ ترجیحی می‌توانند آن پاسخ را تغییر دهند، و به همین دلیل جست‌وجوی زنده بر خواندن جدول با چشم برتری دارد.

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

انتخابگرها را در هر دو طرف تطبیق دهید

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

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

تطابق سیاست به معنای وضعیت نصب‌شده نیست

سیاست منطبق فقط می‌گوید بسته باید محافظت شود؛ هسته هنوز برای انجام محافظت به یک ارتباط امنیتی نیاز دارد. آن‌ها را با ip xfrm state فهرست کنید، یا وقتی strongSwan مذاکره را انجام می‌دهد با swanctl --list-sas، و انتخابگرها و شمارنده‌های هر ورودی را بخوانید.

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

آنچه یک تونل مبتنی بر مسیر هنوز لازم دارد

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

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

پیش از ویرایش هر چیز، مالکیت را روشن کنید

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

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