Check Point VSX VPN: انتخاب پیوند یا ناسازگاری همتا؟
پیش از دستزدن به انتخاب پیوند روی دروازه Check Point VSX، نشانی خارجی، هویت IKE، ترجمه و مجموعه قابلیتهای پشتیبانیشده را ثبت کنید.
دو تغییر متفاوت همان نشانه را میسازند وقتی تونل سایتبهسایت Check Point دیگر بالا نمیآید: همتا نشانی خارجی دیگری میبیند، یا هویت IKE را که اکنون دریافت میکند رد میکند. در یک ضبط گرفتهشده از یک طرف، هر دو یکسان به نظر میرسند. برای تشخیص اینکه کدام مورد را دارید سه بررسی لازم است و هیچکدام از آنها پنجره انتخاب پیوند نیست.
اگر ترتیب را اشتباه کنید، انتخاب مبدأ را تنظیم میکنید تا ناسازگاری هویت را درست کنید. اینگونه همان تونل دو بار درست میشود و پس از تغییر مسیر بعدی دوباره میشکند.
سه شرطی که دو حالت را جدا میکند
شرط یکم: آیا نقطه پایانی پیکربندیشده همتا با نشانیای که واقعاً میرسد میخواند؟ اگر بستهها از نشانیای به دروازه دور برسند که آن را به شیء همتای شما نسبت نمیدهد، مذاکره پیش از هرگونه تبادل هویت شکست میخورد. شرط دوم: آیا هویت IKE در پیشنهاد با مقدار مورد انتظار همتا میخواند؟ این احراز هویت است، نه انتقال. شرط سوم: آیا گزینهای که میخواهید تغییر دهید برای این سیستم مجازی در این نسخه پشتیبانی میشود؟ هیچ تنظیم قابل مشاهدهای به هیچیک از این پرسشها پاسخ نمیدهد.
اگر شرط یکم برآورده نشود، مشکل مسیریابی یا ترجمه دارید. اگر شرط دوم برآورده نشود، مشکل قرارداد همتا دارید. اگر شرط سوم ناشناخته است، پیکربندی را متوقف کنید.
نخست سند همتای خارجی را بسازید
پیش از دستزدن به هر چیزی، سیستم مجازی، نسخه نرمافزار و سطح بهروزرسانی نصبشده را بنویسید. سپس واسطهای خارجی، مسیر بهسوی همتای دور، نشانیهای مبدأ مورد انتظار پیش و پس از NAT، و نقطه پایانی پیکربندیشده همتای دور را ثبت کنید.
پیشوندهای محافظتشده داخلی را در بخشی جدا از آن سند نگه دارید. تغییر یک مبدأ خارجی و تغییر یک نشانی LAN محافظتشده دو عملیات متفاوتاند که تصادفاً در یک سیاست زندگی میکنند.
به هر ضبطی که نگه میدارید جهت اضافه کنید. مذاکرهای که بهصورت محلی آغاز شده و پاسخی به همتای دور میتوانند متفاوت انتخاب کنند، بنابراین ضبط بدون برچسب شاهد ضعیفی است. فایل را با سیستم مجازی و آغازگر برچسب بزنید.
بخوانید انتخاب پیوند در واقع چه چیزی را جدا میکند
راهنمای Check Point درباره انتخاب پیوند در R81.20 سه چیز را جدا میکند که مردم آنها را در یکی ادغام میکنند: همتای دور چگونه نشانی دروازه را تفکیک میکند، کدام مسیر ترافیک خروجی را میبرد، و کدام IP مبدأ استفاده میشود. هر یک به پرسشی متفاوت پاسخ میدهد. هیچیک از آنها هویتی را که همتا احراز میکند تغییر نمیدهد.
همین جداسازی توضیح میدهد چرا تغییر مسیر میتواند نشانی خارجی قابل مشاهده را بدون دستزدن به هویت IKE عوض کند، و چرا تغییر هویت میتواند تونلی را بشکند که مسیریابیاش بیعیب است.
RFC 7296 همین مرز را برای خود IKE میکشد: بار مشخصسازی، نشانی انتقال نیست. سازندگان این تفکیک را پیاده میکنند، آن را بازتعریف نمیکنند.
با شواهد تصمیم بگیرید، نه با پنجره تنظیمات
اگر همتا هویتی ناشناخته یا ناسازگار گزارش کند، شیء همتا یا پیکربندی هویت را درست کنید، نه انتخاب مبدأ را. اگر همتا چیزی گزارش نکند و ضبط شما نشان دهد بستهها از نشانیای غیرمنتظره خارج میشوند، نخست مسیریابی یا ترجمه را درست کنید. اگر هر دو درست به نظر میرسند و تونل هنوز برقرار نمیشود، در سمت دور ضبط بگیرید و آنچه دریافت کرده را مقایسه کنید. تنها زمانی که نشانی و هویت همخوان باشند و مسیر هنوز نادرست باشد، یک گزینه انتخاب پیوند نامزد میشود.
پیش از پیکربندی آن گزینه روی VSX، راهنمای قابلیتهای پشتیبانیشده نسخه مربوطه یا بیانیه صریح سازنده برای بافت سیستم مجازی را بگیرید. گزارش قدیمیتر درباره در دسترس نبودن یک قابلیت، تاریخ است نه ممنوعیت کنونی، و پنجره تنظیمات بیانیه پشتیبانی نیست.
دو سر را همراست کنید و سند را نگه دارید
وقتی طرحی پشتیبانیشده دارید، دسترسی خارجی، پیکربندی نقطه پایانی همتا و توافق هویت را با هم و بهعنوان یک قرارداد بازبینی کنید. سپس پذیرش را برای سه حالت برنامهریزی کنید: اتصال آغازین، اتصالی که طرف دور آغاز میکند، و شکستی که با گسستن مسیر انتظار دارید.
نشانیهای خارجی مشاهدهشده را کنار بافت سیستم مجازی فعال ذخیره کنید. آنگاه تغییر مسیر بعدی با یک قرارداد مستند مقایسه میشود، نه با حافظه کسی از مقدار پیشفرض.