دو دروازه IPsec بدون IP مشترک: جابه‌جایی در صورت خرابی واقعاً چه می‌کند

دروازه A را وسط یک جلسه از کار بیندازید و ببینید تونل یک دقیقه بعد از مسیر B برمی‌گردد؛ اتصال کار می‌کند، شاید تماس تصویری نه. این شکل صادقانه جابه‌جایی سرد بین دو دروازه IPsec با آدرس‌های مستقل است. کلاینت یک نقطه پایانی را دوباره انتخاب می‌کند و رابطه تازه‌ای می‌سازد، که دسترسی را بدون انتقال وضعیت رمزنگاری نشست قدیمی بازمی‌گرداند. مرور این توالی روشن می‌کند طراحی کدام وعده‌ها را می‌تواند نگه دارد.

صحنه را بچینید: دو آدرس، بدون IP شناور

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

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

خرابی را مرور کنید: تشخیص، سپس انتخاب دوباره

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

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

B چه چیزی را می‌تواند به ارث ببرد و چه چیزی را نه

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

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

برقراری رابطه تازه

با انتخاب B، کلاینت تبادل IKE تازه‌ای انجام می‌دهد: مقادیر nonce تازه، مقادیر تازه Diffie-Hellman، شناسه‌های تازه برای انجمن‌های حاصل. احراز هویت دوباره در B انجام می‌شود. اگر طراحی بر اعتبارنامه ماشین تکیه کند، اتصال دوباره می‌تواند بدون نظارت باشد؛ اگر عامل انسانی لازم باشد، کسی باید حاضر باشد تا جابه‌جایی کامل شود.

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

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

دو تونل موازی طراحی دیگری است

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

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

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