keepalive ב-OpenVPN או restart ב-systemd: מה משחזר את המנהרה?

שלושה דברים שונים עלולים להשתבש במנהרה, ו הם דורשים שלוש תגובות שונות. העמית מפסיק להשיב, תהליך הדמון מת, או שהיישום שמאחורי המנהרה מפסיק לשרת. תצורה שמפעילה מחדש את השירות בכל אחד מהם אינה פיקוח זהיר; היא פעולה גסה אחת שמופעלת על כשלים לא קשורים. השוואה של מה שכל מנגנון באמת יכול להבחין בו מבהירה את חלוקת העבודה.

שלושה כשלים שנראים כאחד

שקט של העמית פירושו שהצד השני הפסיק לשלוח, ו OpenVPN יכול לזהות זאת בעצמו מכיוון שהפעימה בידיו. מות התהליך פירושו שהדמון יצא, מה שמנהל השירותים מבחין בו ו-OpenVPN אינו יכול. כשל היישום פירושו שהמנהרה תקינה ומשהו מאחוריה אינו, ולאף אחד משני המנגנונים האחרים אין דרך לדעת זאת. כל אחד מהם זקוק לתגובה אחרת, ואף אחד מהם אינו זהה להבחנה שהמנהרה פעילה.

אלה אותות שונים משכבות שונות, ולכל אחד יש בעלים שיכול לפעול לפיו בלי לנחש. ערבובם מייצר מערכת שמפעילה מחדש על תסמינים שאינה יודעת לפרש.

כתבו את שלושת המקרים לפני שתשנו טיימר כלשהו. הרשימה עצמה מלמדת בדרך כלל שמבקשים ממנגנון אחד לכסות את כל השלושה.

למה בעצם מתרחב keepalive

ההוראה keepalive היא קיצור, וההתרחבות משתנה לפי מצב. בשרת, keepalive 10 60 הופך ל-ping מקומי כל עשר שניות, לזמן המתנה מקומי להפעלה מחדש של 120 שניות ולערכים 10 ו-60 שנשלחים ללקוחות. זמן ההמתנה של השרת מוכפל בכוונה כדי שלקוח יקבל הזדמנות להפעיל מחדש לפני שהשרת מוותר. קראו את הצורה המורחבת בתצורה הפועלת, ולא את הקיצור בפרופיל.

הכפלה זו היא הסיבה לכך שכל תיאור שטוען ששני הקצוות מופעלים מחדש אחרי שישים שניות שגוי. היא גם מסבירה מדוע שני הקצוות אינם מרפרפים יחד כשמסלול נפגע.

הפעימה היא תעבורת עמיתים של OpenVPN, לא בדיקת ICMP של איזה מארח ציבורי. תשובה מוכיחה רק שהקצה המרוחק של המנהרה חי. אין בה דבר על מסד הנתונים או שירות האינטרנט שהמשתמש באמת צריך.

מה Restart=on-failure אינו מנטר

קראו את היחידה המותקנת לפני שמוסיפים עקיפה. Restart=on-failure מגיב לתנאי כשל תהליך מתועדים, וזה אינו זהה לניטור מצב החיבור. הוא אינו מופעל מפני שהתחילה התחברות מחדש פנימית, וליציאה נקייה יש משמעות שונה מקריסה.

ההבחנה הזו חשובה מפני שהפעלה מחדש פנימית משאירה את אותו תהליך בחיים. היחידה אינה רואה דבר, המנהרה משתחזרת מעצמה, וזו התוצאה הנכונה.

קבעו את RestartSec ומגבלות ההתחלה בכוונה, אחרת לופ קריסות יכה בשער ויקבור את השגיאה האמיתית תחת הודעות הפעלה מחדש. מגבלת הפעלה מחדש שמופעלת משאירה את היחידה בכשל, וזה גלוי, בעוד שלופ בלתי מוגבל אינו גלוי.

ping-restart ו-ping-exit אינם ניתנים להחלפה

ping-restart מפעיל את ההפעלה מחדש הפנימית של OpenVPN ושומר על התהליך. ping-exit מסיים את התהליך באותו סוג של זמן המתנה, מה שמעביר את ההחלטה למנהל השירותים. הם סותרים זה את זה, ובחירה בשני משנה מי הבעלים של השחזור. ההבדל הוא מי מחליט לנסות שוב, וכמה מצב שורד את הניסיון.

אם תבחרו ביציאה בסוף זמן ההמתנה, היחידה זקוקה למדיניות הפעלה מחדש ולטיפול במצב יציאה שמתאימים, אחרת כשל חיות נראה כמו עצירה קבועה. אפשרויות התמדה יכולות גם לשמר ממשקים ומסלולים לאורך הפעלה מחדש פנימית, אבל לא לאורך יציאת תהליך.

בחרו מחזור חיים אחד לכל פריסה וכתבו מדוע. פרופיל שנושא את שתי ההוראות הוא פרופיל שלא החליט.

בדקו כל כשל כמקרה נפרד

דמו עמית שקט, דמון שנהרג ויישום שאינו זמין בחלון מאושר, ואז בדקו איזה שחזור הופעל. עמית שקט אמור להפיק התחברות מחדש פנימית, תהליך שנהרג הפעלה מחדש של היחידה, והפסקת יישום אף אחד מאלה. כששני מקרים מפיקים את אותה פעולה, הבעלות עדיין מעורבת.

שחזור חוזר אינו תיקון. אישורים שנדחו או שני לקוחות שחולקים שם אפקטיבי ימשיכו להחליף זה את זה, וטיימרים מהירים יותר רק הופכים את הרפרוף הזה למהיר יותר.