چگونه MOBIKE یک VPN IKEv2 را هنگام تغییر شبکه زنده نگه میدارد
MOBIKE وقتی دستگاه شبکه را تغییر میدهد، یک اتصال IKEv2 پشتیبانیشده را بهروزرسانی میکند۔ مسیریابی، فیلترکردن و بازیابی نشست برنامه همچنان باید کار کنند۔
تلفنی Wi-Fi را ترک میکند و به شبکه سلولی میپیوندد، لپتاپی از Ethernet به نقطه دسترسی منتقل میشود، و تونل IKEv2 یا دوام میآورد یا نه۔ MOBIKE افزونهای است که به آن اجازه دوام میدهد، با گفتن به طرف دور که نشانی مبدأ تغییر کرده است بهجای شروع دوباره از صفر۔ کاری که نمیکند این است که هر برنامه را در طول تغییر زنده نگه دارد۔ اینها دو ادعا هستند، و دومی همان چیزی است که مردم معمولاً منظورش هستند۔
گذار را مرحله به مرحله پیش ببرید، چون هر مرحله به شکلی متفاوت شکست میخورد۔
بهروزرسانی واقعاً چه چیزی را تغییر میدهد
تا زمانی که انجمن امنیتی هنوز معتبر است، آغازگر نشانی جدید خود را میآموزد و بهروزرسانیای به پاسخدهنده میفرستد، که سپس از همان نشانی برای همان انجمن استفاده میکند۔ پارامترهای امنیتی از صفر دوباره مذاکره نمیشوند۔ این تمام فایده است: نه دور احراز هویت تازه، نه تبادل کلید تازه، نه درخواستی از کاربر۔ همچنین یعنی وضعیت بازمانده هنوز به نشست قدیمی تعلق دارد۔
MOBIKE همچنین میتواند ترافیک را به درونپوشانی UDP منتقل کند، و به همین دلیل یک تونل سالم گاهی پس از تغییر شبکه شروع به استفاده از درگاه 4500 میکند۔ آن گذار بهخودیخود ثابت نمیکند که NAT شناسایی شده است، هرچند این دو اغلب با هم دیده میشوند۔
آیا نمایه شما واقعاً آن را فعال میکند
هر دو طرف باید افزونه را پشتیبانی کنند، و استقرار باید آن را فعال کند۔ در strongSwan رفتار برای هر اتصال قابل پیکربندی است، و تغییرات رابط یا مسیر میتواند در صورت نیاز جستوجوی مسیر و بهروزرسانی را راه بیندازد۔ تنظیمات واقعی اتصال را بررسی کنید بهجای آنکه فرض کنید هر نمایه IKEv2 آن را روشن میکند۔ نمایهای که از راهنمایی قدیمیتر از این ویژگی کپی شده باشد، منبع رایج این موضوع است۔
وضعیت مذاکرهشده در دو طرف مرجع است، نه مستندات خانواده محصول۔
گذار را مرحله به مرحله پیش ببرید
وضعیت برنامه را پیش از تغییر شبکه ثبت کنید۔ سپس تغییر دهید، و بعد وضعیت کارخواه و کارساز را ثبت کنید۔ نشانی گمشده، همتای دستنیافتنی و برنامهای که باید نشست خودش را دوباره متصل کند سه پیامد متفاوتاند۔ تنها دو مورد نخست به لایه VPN تعلق دارند؛ سوم به هر پروتکلی که برنامه با آن سخن میگوید۔
یک جابهجایی شبکه را با یک آزمون ساکن مقایسه کنید تا بدانید کدام رویداد مشکل را راه میاندازد۔ اندازهگیری توانعبوری در شبکه نهایی نمیتواند یک گذار را بازتولید کند۔ مقصد را میسنجد، نه سفر را۔
لایههای شکست را جدا کنید
یک نشست دیرپای TCP میتواند به دلایلی بیرون از تبادل IKEv2 شکست بخورد۔ شبکه جدید ممکن است متفاوت فیلتر کند، متفاوت نشانییابی کند یا متفاوت مسیریابی کند۔ ممکن است نشانی تونل اصلاً تغییر نکند در حالی که مسیر زیر آن تغییر میکند۔ برای همین است که اتصال دوباره برنامه میتواند چیزی را درست کند که VPN هرگز نشکسته است۔
در حین بازیابی هم سیاست مسدودسازی را در جای خود نگه دارید۔
جابهجایی خودکار و قاعدهای که ترافیک مستقیم را بازمیدارد دو کنترل متفاوتاند، و خاموشکردن دومی تا اولی کار کند معامله بدی است۔ اگر بهروزرسانی جابهجایی شکست بخورد، مسدودسازی باید دوام بیاورد بهجای آنکه ترافیک را دور تونل نشت دهد۔
وقتی تکرار شد چه چیزی را ثبت کنیم
مهرزمانها و هر دو مقدار نشانی را از دو طرف نگه دارید۔ آن سابقه نشان میدهد که آیا بهروزرسانی پیش از ازدسترفتن تماس برنامه کامل شده بود، که تفاوت میان یک اشکال جابهجایی و یک پایان مهلت برنامه است۔ سپس جهت جابهجایی را مقایسه کنید: رفتن از Wi-Fi به شبکه سلولی با عکس آن متقارن نیست۔ یک جهت میتواند کار کند در حالی که دیگری شکست میخورد۔
این نامتقارنی بهقدری رایج است که نخستین چیزی باشد که باید آزمود۔
با سابقه در دست، حادثه از اینکه یک نماد قطعشده دیگر باشد بازمیایستد و به رویدادی در زنجیرهای با مالک شناختهشده تبدیل میشود۔ و این تمام چیزی است که یک مرور صادقانه میتواند وعده دهد۔