keepalive یک اتصال دوباره نیست: بر اساس خرابی موجود انتخاب کنید
یک بسته یک نگاشت را زنده نگه می‌دارد؛ اتصال دوباره رابطه را از نو می‌سازد. سازوکار را با خرابی تطبیق دهید و سپس با یک درخواست واقعی بررسی کنید.
keepalive و اتصال دوباره با هم پیکربندی می‌شوند اما دو مسئلهٔ متفاوت را حل می‌کنند، به همین دلیل تنظیم یکی به‌ندرت دیگری را درست می‌کند. keepalive ترافیک کوچکی می‌فرستد تا یک مدخل حالت را زنده نگه دارد یا متوجه شود که همتا پاسخ‌دادن را متوقف کرده است. اتصال دوباره آنچه شکسته است را فرو می‌ریزد و رابطه را از نو می‌سازد، شامل کلیدها، نشانی‌ها و مسیرها. سازوکاری را انتخاب کنید که با خرابی می‌خواند، نه آن‌که دستگیره‌اش را از قبل می‌شناسید. دو پرسش این را تعیین می‌کند: آیا مسیر مرده است، یا چیزی میان همتاها آن را فراموش کرده است؟
وقتی نگاشت مشکل است
تونلی که فقط پس از دقیقه‌ها سکوت می‌میرد معمولاً یک مدخل ترجمه را از دست می‌دهد نه یک همتا. گزینهٔ PersistentKeepalive برای وضعیت NAT و دیوار آتش وجود دارد، و یادداشت‌های خود پروژه آن را درست همین‌طور توصیف می‌کنند نه به‌عنوان بررسی سلامت. فاصلهٔ چند ده ثانیه یک مدخل را گرم نگه می‌دارد، در حالی که بسته‌ای در هر ثانیه تصمیمی دربارهٔ باتری است نه دربارهٔ اطمینان. OpenVPN به همان نتیجه از راه ping و ping-restart می‌رسد، که نخست سکوت را می‌بینند و سپس بر اساس آن عمل می‌کنند.
این تنظیمات میان پروتکل‌ها هم قابل تبادل نیستند. سیاست همتای مرده در IKEv2، زمان‌سنج ping در OpenVPN و keepalive در WireGuard به یک پرسش با سه نحو و سه مقدار پیش‌فرض متفاوت پاسخ می‌دهند، پس کپی‌کردن یک عدد میان آن‌ها حدسی است که لباس تنظیم پوشیده است.
وقتی رابطه رفته است
اگر همتا نشانی را عوض کند، اعتبارنامه منقضی شود یا طرف دور راه‌اندازی دوباره شود، بسته‌های کوچک درمان نیستند. اتصال دوباره باید حالت را از نو بسازد : نشانی بگیرد، مسیرها را دوباره نصب کند، کلیدها را دوباره مذاکره کند و در برخی استقرارها کاربر را دوباره احراز هویت کند.
کارخواهانی که بی‌نظارت دوباره وصل می‌شوند یک گواهی یا راز ذخیره‌شده دارند. کارخواهی که از انسان می‌پرسید دقیقاً وقتی شکست می‌خورد که کسی حاضر نیست، و همان سناریویی است که اتصال دوباره در آن اهمیت داشت. این یک انتخاب طراحی است که ماه‌ها پیش گرفته شده، نه تنظیمی که بتوانید هنگام قطعی تغییر دهید.
چیزی که هیچ‌کدام اثبات نمی‌کند
تونل می‌تواند دوباره وصل، کلیددار و مسیردار باشد در حالی که سرویس پشت آن پایین است، و keepalive می‌تواند یک نگاشت را برای نشستی باز نگه دارد که سرور آن ساعت‌هاست رفته است. هر دو سازوکار می‌توانند موفقیت گزارش کنند در حالی که چیزی که واقعاً برایتان مهم است در دسترس نیست.
به همین دلیل آزمون با یک درخواست واقعی تمام می‌شود. پس از فاصله‌ای که برایتان مهم است چیزی را از تونل بفرستید، سپس خرابی‌ای را که برایش طراحی کرده‌اید جداگانه برانگیزید: یک دورهٔ بی‌کاری برای حالت نگاشت، یک راه‌اندازی دوباره یا تغییر نشانی برای حالت اتصال دوباره.
مسدودکردن ترافیک مستقیم تصمیمی جداست
حلقهٔ اتصال دوباره می‌تواند کاملاً سالم باشد در حالی که برنامه‌ای بی‌صدا از مسیر معمولی استفاده می‌کند، و این نشت است نه خرابی. اگر شرط این است که چیزی بیرون از تونل نرود، آن را صریح در پیکربندی کارخواه بگویید و با پایین‌آوردن تونل و دیدن این‌که چه چیزی هنوز وصل می‌شود اثباتش کنید. هیچ‌یک از دو سازوکار این رفتار را ایجاب نمی‌کند و هیچ نظم تکرارکردنی آن را برقرار نمی‌سازد.
ثبت کنید کدام سازوکار اجرا شد و آیا درخواست تازه‌ای پس از آن موفق شد. این دو واقعیت همان چیزی است که مهندس بعدی لازم دارد و هیچ‌کدام در یک نماد وضعیت دیده نمی‌شود. خطی در گزارش که می‌گوید کارخواه دوباره وصل شد با درخواستی که کار کرد یکی نیست.
سیاست را بنویسید، نه فقط عدد را
این جفت را در یک جمله بگذارید: فاصلهٔ بی‌کاری، آستانهٔ زنده‌بودن، چه چیزی بازسازی را برمی‌انگیزد ، و کارخواه در حین تکرار چه می‌کند. بدون آن جمله، هر رخداد آینده همان بحث را دوباره باز می‌کند که آیا keepalive خیلی کوتاه است یا اتصال دوباره خیلی کند.
یادداشت‌های WireGuard دربارهٔ محدودیت‌ها یادآوری سودمندی است که keepalive راه‌حلی دورزدنی برای جعبه‌های میانی است نه طراحی عمومی زنده‌بودن. پیش از افزایش بسامد در پاسخ به مشکلی که نمی‌تواند حلش کند، آن محدودیت را بخوانید.