کوتاه کردن تایمر DPD انتقال اضطراری VPN را سریعتر نمیکند
بازیابی چهار مرحله دارد و تایمر همتای مرده یکی از آنها را کنترل میکند. تشخیص، انتخاب همتا، مسیرها و بازیابی برنامه را جداگانه اندازه بگیرید.
تونلها قطع میشوند، بازیابی نود ثانیه طول میکشد و تایمر همتای مرده روی ده تنظیم شده است، پس تایمر سرزنش میشود. این استدلال سه مرحله را نادیده میگیرد که پس از تشخیص رخ میدهند و معمولاً بیشتر زمان را میگیرند. تشخیص زندهبودن سکوت را متوجه میشود؛ سپس انتخاب همتا، احراز هویت، نصب مسیر و اتصال مجدد برنامه هر یک نوبت خود را میگیرند. کوتاه کردن مرحله اول نمیتواند مراحل دیگر را کوتاه کند و میتواند به سیستمی که از قبل در تقلا بود آشفتگی اضافه کند.
چهار مرحله که میتوانید یکی از آنها را زمان بگیرید
بازیابی را بهصورت چهار رویداد با برچسب زمانی بنویسید. خرابی قابل مشاهده میشود: آخرین ترافیک محافظتشده مفید و اولین درخواست ناموفق. مکانیسم مالک واکنش نشان میدهد: تشخیص زندهبودن، پایشگر مسیر یا محرک مستند دیگری. گزینه جایگزین قابل استفاده میشود: انتخاب همتا، احراز هویت، ارتباط جدید و مسیری که واقعاً ترافیک موردنظر را حمل میکند. برنامه بازیابی میشود: عملیات تازهای موفق میشود و آنچه در جریان بود نتیجه مشخصی پیدا میکند.
قواعد زندهبودن IKEv2 شواهدی درباره همتا و تبادلاتش توصیف میکنند و هیچ چیزی درباره پایگاه داده یا سرویس فایلی پشت آن همتا نمیگویند. خواندن یک پایان مهلت زندهبودن بهعنوان بررسی سلامت کل مسیر همان اشتباهی است که شکار تایمر را آغاز میکند.
چرا تایمر کمترین عدد جالب است
مقادیر پیکربندیشده واحدهای قابل تبادل نیستند. برخی فاصلههای تلاش مجدد هستند، برخی سقفهای بالای یک تلاش، و برخی همزمان با دیگران اجرا میشوند. جمع کردن آنها عددی میسازد که شبیه پیشبینی به نظر میرسد و مانند شایعه رفتار میکند. مستندات فیلدی را که میخواهید لمس کنید بخوانید و توجه کنید کدام یک از این سه نوع است.
مراحل دیگر اصلاً تایمر نیستند. عقبرفت اتصال مجدد، درخواست تعاملی احراز هویت یا کلاینتی که پیکربندی خود را فقط هنگام راهاندازی مجدد بازبینی میکند، هر یک میتوانند بر قطعی غالب شوند در حالی که هر تایمر پروتکل بهراحتی پایین نشسته است.
مرحلهای را که واقعاً کند است اندازه بگیرید
خرابی را یک بار با برچسب زمانی در هر دو طرف ثبت کنید، سپس چهار رویداد را مقایسه کنید نه شمارندههای خود پروتکل. یک پنجره مشاهده که درست انجام شود از یک ماه تنظیم بهتر است.
ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"
اگر نقطه پایانی جایگزین هرگز پاسخ ندهد، هیچ تغییری در تایمر کمکی نمیکند، زیرا دسترسیناپذیری مسئله تشخیص نیست. اگر وضعیت امنیتی جدید سریع شکل بگیرد اما مسیر هنوز به مسیر مرده اشاره کند، مشکل در نصب مسیر است و یک تنظیم دیگر زندهبودن فقط آشفتگی اضافه میکند.
گزینه جایگزین باید از قبل قابل استفاده باشد
پشتیبانی که در یک پیکربندی تعریف شده، پشتیبانی قابل استفاده نیست. باید از شبکه فعلی کلاینت قابل دسترسی باشد، بتواند همان هویت را احراز کند و مجاز باشد همان ترافیک را تحت همان سیاست حمل کند. اگر هر یک از این سه شکاف را در زمان قطعی کشف کنید، بحث تایمر بیمعنی میشود. گزینه جایگزین را زمانی که اصلی سالم است آزمایش کنید، زیرا تنها زمانی است که میتوانید هر دو گزارش را کنار هم بخوانید.
گزینه جایگزین را از قبل فراهم کنید، آن را عمداً زمانی که اصلی سالم است آزمایش کنید و ثبت کنید کدام یک از چهار مرحله زمان میگیرد. همین ثبت است که تغییر بعدی را بهجای حدس، اندازهگیری میکند.
آشفتگی بازگشت و مسیر مدیریت
بازگرداندن اصلی تصمیمی جداگانه است. بازگشت تهاجمی میتواند کاری را که قبلاً روی پشتیبان بازیابی شده بود قطع کند، و یک مسیر ناپایدار میتواند مانند تونلی ناپایدار به نظر برسد در حالی که خطای واقعی مسیری است که مدام بین دو گزینه برابر نوسان میکند.
دو مسیر با هزینه برابر و بدون ترجیح، منبع معمول نوسان قابل مشاهده هستند، زیرا هر پایشگر به انتخاب دیگری واکنش نشان میدهد. تصمیم بگیرید کدام مسیر در شرایط عادی ترجیح دارد و آن ترجیح را در پیکربندی صریح کنید نه اینکه آن را به ترتیب مسیرها بسپارید. رفتار بازگشت مطلوب و مالک آن را از قبل تعریف کنید. تنظیمات قبلی و یک مسیر مدیریت مستقل را نگه دارید، زیرا تغییری که دسترسی خودتان را در زمان قطعی حذف کند، یک رخداد شبکه را به بازدید حضوری تبدیل میکند.
سپس همان بار کاری را تکرار کنید و همان چهار برچسب زمانی را مقایسه کنید. بازیابی کوتاهتری که برنامه را همچنان منتظر همان مسیر گمشده یا ورود به سیستم نگه دارد پیشرفت نیست، بلکه عددی متفاوت روی همان نمودار است.