یک WAN خصوصی می‌تواند بسته‌های بیرونی یک تونل IPsec را حمل کند، بنابراین آدرس‌های همتا لازم نیست آدرس‌های عمومی اینترنت باشند. چیزی که تغییر می‌کند مسیری است که این بسته‌های بیرونی طی می‌کنند و مجوزهای موجود روی رابطی است که آن‌ها را دریافت می‌کند. روی SRX، مسیر کنترل بیرونی، اتصال رابط تونل و سیاست ترافیک ارسال‌شده سه شیء جداگانه هستند. عیب‌یابی یکی در حالی که دو مورد دیگر اشتباه هستند، دلیل معمول پایین ماندن یک تونل است.

ابتدا مسیر بیرونی IKE را ثبت کنید

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

وضعیت نصب‌شده را با این مورد بررسی کنید: show security ike sa و پیکربندی را با این مورد: show configuration security ike. اولی می‌گوید فاز 1 وجود دارد یا نه؛ دومی می‌گوید دستگاه فکر می‌کند باید چه کار کند.

رابط تونل را به سیاست درست متصل کنید

یک VPN مبتنی بر مسیریابی یک رابط تونل را به یک شیء VPN متصل می‌کند و پیشوندهای محافظت‌شده به آن رابط مسیریابی می‌شوند. ثبت کنید کدام رابط، کدام مسیر و کدام سیاست برنامه‌ها را بین ناحیه‌های مربوطه مجاز می‌کند. ناحیه‌ای به نام trust یک ظرف سیاست است و نام آن ثابت نمی‌کند که بسته‌های کنترل یا داده لازم مجاز هستند.

به‌جای یک نمودار قدیمی، اتصال‌های واقعی را بخوانید: show configuration security ipsec vpn برای تنظیم اتصال به رابط و show configuration security policies برای قواعدی که به ناحیه تونل ارجاع می‌دهند.

اگر مسیر محافظت‌شده جای دیگری را نشان دهد، تونل می‌تواند بالا باشد در حالی که ترافیک هرگز وارد آن نمی‌شود. این یک مشکل مسیریابی با لباس IPsec است.

مسیر همتا را روی underlay نگه دارید

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

این را با این مورد بررسی کنید: show route 198.51.100.10، با جایگزین کردن آدرس واقعی همتا، و تأیید کنید که گام بعدی یک رابط تونل نیست.

کنترل و سرویس را به ترتیب بررسی کنید

از پایین به بالا کار کنید: وضعیت فاز 1، وضعیت فاز 2 و سپس یک جریان واقعی برنامه. show security ipsec sa انجمن‌های امنیتی را فهرست می‌کند و show security flow session destination-prefix 10.60.0.0/16 نشان می‌دهد آیا نشست‌های ارسال‌شده برای شبکه محافظت‌شده ایجاد می‌شوند.

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

مسیر همتا، مجوز host-inbound، اتصال تونل، مسیر داخلی و سیاست برنامه را با هم ثبت کنید. این پنج سابقه نشان می‌دهند کدام لایه مسئول یک خرابی آینده است، بدون تکیه بر برچسب پورت.

مقالات مرتبط