جابه‌جایی اضطراری VPN: وقتی مسیر بازگشت روی تونل قدیمی می‌ماند
تونل پشتیبان تا زمانی که پاسخ‌ها هم از آن استفاده نکنند، جابه‌جایی اضطراری نیست. مسیرهای هر دو سایت را ثبت کنید، هر مرحله را آزمایش کنید و تصمیم بگیرید برای نشست‌های موجود چه اتفاقی می‌افتد.
تونل پشتیبان بالا می‌آید، تونل اصلی از کار می‌افتد و برنامه همچنان به پایان مهلت می‌رسد. در هر دو سایت وضعیت تونل سالم به نظر می‌رسد، و همین موضوع گیج‌کننده است. جابه‌جایی‌ای که درخواست‌ها را به پشتیبان منتقل می‌کند اما پاسخ‌ها را روی مسیر قدیمی رها می‌کند، جابه‌جایی نیست. راهنمای زیر مسیر بازگشت را آزمایش می‌کند، نه فقط مصافحه را.
ابتدا مسیرها را در هر دو طرف ثبت کنید؛ دید از یک سایت نمی‌تواند مسیر نامتقارن را نشان دهد. این همچنین مرحله‌ای است که تحت فشار زمان بیشتر از همه نادیده گرفته می‌شود.
مسیرهای هر دو سایت را پیش از آزمایش ثبت کنید
برای هر پیشوند حفاظت‌شده، مسیر اصلی، مسیر پشتیبان و ترجیحی که بین آن‌ها انتخاب می‌کند را بنویسید. دروازه LAN پشت هر نقطه پایانی VPN را هم شامل شوید، زیرا نقطه پایانی به‌ندرت آخرین گام است.
سنجه‌های ایستا، مسیرهای ردیابی‌شده و مسیریابی پویا واجد شرایط بودن را متفاوت بیان می‌کنند. بدانید طرح شما کدام را استفاده می‌کند و برای فعال شدن گزینه جایگزین چه لازم است. شرط را کنار مسیر بنویسید، مثلاً سنجه پایین‌تر تا شکست بررسی.
این کار را در هر دو سایت انجام دهید. پشتیبانی که در یک طرف ترجیح داده می‌شود و در طرف دیگر نادیده گرفته می‌شود، دقیقاً همان عدم تقارنی را ایجاد می‌کند که می‌خواهید از آن اجتناب کنید.
در هر مرحله درخواست‌ها و پاسخ‌ها را ببینید
از یک برنامه بی‌خطر و مجاز استفاده کنید و سه مرحله را ببینید: عادی، خرابی مسیر اصلی و بازیابی. در هر مرحله ثبت کنید کدام تونل درخواست و کدام پاسخ را حمل می‌کند. یک نشانی همتا که در دسترس است ثابت نمی‌کند مسیر حفاظت‌شده برنامه کار می‌کند. در هر دو سایت ثبت کنید تا جریان یک‌طرفه دیده شود.
اگر درخواست‌ها جابه‌جا می‌شوند و پاسخ‌ها نه، مسیر سایت دور به پیشوند کلاینت و ترجیح آن برای پشتیبان را بررسی کنید. این یک تصمیم مسیریابی است، نه خرابی تونل.
پس از آزمایش وضعیت اولیه را بازگردانید و تأیید کنید که مسیر اصلی دوباره ترجیح داده می‌شود. مسیر اصلی بازگردانده‌شده‌ای که ترجیح داده نمی‌شود، طراحی جابه‌جایی ناتمام است.
هنگام تغییر دروازه، وضعیت نشست را مدیریت کنید
فایروال‌ها و NAT می‌توانند وضعیت اتصال را روی یک دروازه نگه دارند، و تغییر مسیر به دروازه دیگر آن را منتقل نمی‌کند. برخی برنامه‌ها خودشان دوباره متصل می‌شوند؛ برخی دیگر تا برقراری مجدد نشست شکست می‌خورند. اگر پشتیبان منبع عمومی یا نشانی خصوصی ترجمه‌شده را تغییر دهد، قواعد دسترسی از راه دور هم ممکن است واکنش نشان دهند. هر راه‌اندازی مجدد مورد انتظار نشست را مستند کنید، نه وعده جابه‌جایی بدون وقفه بدهید.
در جایی که برنامه نیاز دارد، آدرس‌دهی پایدار را حفظ کنید. طراحی جابه‌جایی‌ای که نشانی منبع را برای هر نشست تغییر می‌دهد یک انتخاب طراحی است و باید نوشته شود. همان انتخاب تعیین می‌کند کاربران چقدر از قطعی را واقعاً متوجه می‌شوند.
برنامه‌ای را آزمایش کنید که نشست طولانی نگه می‌دارد، نه فقط یک درخواست جدید.
مسیر اصلی را بازگردانید و نوسان را بررسی کنید
تأیید کنید که اعلان‌های مسیر یا ترجیح‌ها بدون نوسان تثبیت می‌شوند. مسیر اصلی نوسان‌کننده می‌تواند مخرب‌تر از یک قطعی روشن باشد، زیرا هر گذار وضعیت را بازنشانی می‌کند.
مدیریت دروازه را از طریق مسیر بازیابی در دسترس نگه دارید تا خود آزمایش شما را بیرون نکند. مراحل، مسیرهای مشاهده‌شده و زمان بازیابی را ثبت کنید؛ همان ثبت است که جابه‌جایی بعدی را قابل پیش‌بینی می‌کند. یادداشت‌های strongSwan درباره ارسال زمانی مفیدند که نقاط پایانی میزبان‌های Linux باشند.