keepalive אינו חיבור מחדש: בחרו לפי התקלה שיש לכם
חבילה אחת משאירה מיפוי בחיים; חיבור מחדש בונה את הקשר מחדש. התאימו את המנגנון לתקלה, ואז אמתו בבקשה אמיתית.
keepalive וחיבורים מחדש מוגדרים באותה נשימה אך פותרים בעיות שונות, ולכן כוונון של האחד ממעט לתקן את האחר. keepalive שולח תעבורה קטנה כדי להשאיר רשומת מצב בחיים או כדי להבחין שעמית הפסיק להשיב. חיבור מחדש מפרק את מה שנשבר ובונה את הקשר מחדש, כולל מפתחות, כתובות ומסלולים. בחרו במנגנון שמתאים לתקלה, לא בזה שאתם כבר מכירים את הכפתור שלו. שתי שאלות מכריעות: האם המסלול מת, או שמשהו בין העמיתים שוכח אותו?
כשהמיפוי הוא הבעיה
מנהרה שמתה רק לאחר דקות של שקט מאבדת בדרך כלל רשומת תרגום ולא עמית. ה PersistentKeepalive של WireGuard קיים בשביל מצב NAT וחומת אש, וההערות של הפרויקט עצמו מתארות אותו בדיוק כך ולא כבדיקת בריאות. מרווח של כמה עשרות שניות משאיר רשומה חמה, בעוד שחבילה בכל שנייה היא החלטת סוללה ולא החלטת אמינות. OpenVPN מגיע לאותו מקום דרך ping ו ping-restart , שמבחינים קודם בשקט ואז פועלים לפיו.
גם ההגדרות האלה אינן ניתנות להחלפה בין פרוטוקולים. מדיניות עמית מת של IKEv2, טיימר ping של OpenVPN ו-keepalive של WireGuard עונים על אותה שאלה בשלושה תחבירים ושלושה ערכי ברירת מחדל שונים, ולכן העתקת מספר ביניהם היא ניחוש לבוש ככוונון.
כשהקשר נעלם
אם העמית מחליף כתובת, האישור פג או הקצה המרוחק מופעל מחדש, חבילות קטנות אינן התיקון. החיבור מחדש חייב לבנות מחדש מצב : לקבל כתובת, להתקין מסלולים מחדש, לנהל משא ומתן מחדש על מפתחות ובפריסות מסוימות לאמת משתמש מחדש.
לקוחות שמתחברים מחדש ללא השגחה מחזיקים תעודה או סוד שמור. לקוח שהיה שואל אדם נכשל בדיוק כשאין איש נוכח, וזה התרחיש שבו החיבור מחדש היה חשוב. זו בחירת תכנון שנעשתה חודשים קודם, לא הגדרה שאפשר לשנות בזמן תקלה.
מה שאף אחד מהם לא מוכיח
מנהרה יכולה להיות מחוברת מחדש, עם מפתחות ומסלולים, בזמן שהשירות שמאחוריה למטה, ו-keepalive יכול להחזיק מיפוי פתוח עבור הפעלה שהשרת שלה נעלם לפני שעות. שני המנגנונים יכולים לדווח על הצלחה בזמן שהדבר שבאמת חשוב לכם אינו זמין.
לכן הבדיקה מסתיימת בבקשה אמיתית. שלחו משהו דרך המנהרה אחרי המרווח שחשוב לכם, ואז עוררו בנפרד את התקלה שעבורה תכננתם: תקופת חוסר פעילות למקרה המיפוי, הפעלה מחדש או שינוי כתובת למקרה החיבור מחדש.
חסימת תעבורה ישירה היא החלטה נפרדת
לולאת חיבור מחדש יכולה להיות בריאה לחלוטין בזמן שיישום משתמש בשקט במסלול הרגיל, וזו דליפה ולא תקלה. אם הדרישה היא ששום דבר לא ייצא מחוץ למנהרה, אמרו זאת במפורש בהגדרות הלקוח והוכיחו זאת על ידי הורדת המנהרה וצפייה במה שעדיין מתחבר. אף אחד מהמנגנונים לא מרמז על ההתנהגות הזו, ושום משמעת ניסיונות חוזרים לא מבססת אותה.
תעדו איזה מנגנון רץ והאם בקשה חדשה הצליחה אחריו. שתי העובדות האלה הן מה שהמהנדס הבא צריך, ואף אחת מהן לא נראית בסמל סטטוס. שורת יומן שאומרת שהלקוח התחבר מחדש אינה זהה לבקשה שעבדה.
כתבו את המדיניות, לא רק את המספר
שימו את הצמד במשפט אחד: מרווח חוסר הפעילות, סף החיות, מה מפעיל בנייה מחדש , ומה הלקוח עושה בזמן שהוא מנסה שוב. בלי המשפט הזה, כל תקרית עתידית פותחת מחדש את אותה מחלוקת אם ה-keepalive קצר מדי או החיבור מחדש איטי מדי.
ההערות של WireGuard על מגבלות הן תזכורת שימושית שה-keepalive הוא עקיפה עבור קופסאות ביניים ולא תכנון חיות כללי. קראו את המגבלה הזו לפני שאתם מעלים את התדירות בתגובה לבעיה שהיא לא יכולה לפתור.