strongSwan נשאר למטה אחרי אתחול של peer: שחזור מנהרה אחת

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

נטשו את האתחול הגלובלי, שמרו על הראיות שלו

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

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

swanctl --list-conns
swanctl --list-sas

שימו יזימה וניסיונות חוזרים על החיבור שחוזר

בפריסת swanctl.conf ההגדרות האלה יושבות ברמת החיבור וה-child ולא במדיניות גלובלית. הקטע שלמטה הוא דוגמה מצד המזרים שמניחה שההצעות, האימות והבוררים כבר נכונים.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action מחליט מה קורה כשה-child נטען: start מזרים מיד, ואילו trap מתקין מדיניות שמפעילה יזימה כשמופיע תעבורה מתאימה. כתיבת trap|start דורשת strongSwan 5.9.6 ואילך, אז בדקו את הגרסה לפני שמעתיקים את השורה. dpd_action=restart מבקש משא ומתן חדש ברגע שה-peer מוכרז מת, ו-keyingtries=0 ברמת החיבור מאפשר ניסיונות נוספים עד להצלחה או לשגיאה קבועה. תחת IKEv2 ל-dpd_timeout אין שום השפעה, כי שליחה חוזרת רגילה היא שקובעת מתי ה-peer לא מגיב.

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

דעו מאיזה אירוע אתם משחזרים

שלוש תקלות נראות זהות בלוח בקרה ודורשות הגדרות שונות. חיבור ראשוני שלא עלה מעולם הוא בעיית תצורה או נגישות. peer שהפסיק להגיב הוא מקרה ה-DPD. child שה-peer סגר אותו במפורש הוא אירוע מדיניות עם close_action משלו, ש-DPD לעולם לא מבחין בו. קריאת הלוג סביב הניתוק אומרת לכם איזו מהשלוש יש לכם, והתשובה משנה את התיקון.

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

אמתו לפי שם, לא לפי מצב הדמון

קראו את החיבור וה-child שלו לפי שם כשה-peer עדיין למטה, ואז שוב כשהוא חוזר; ההבדל בין שתי הפלטים האלה הוא הראיה.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

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

אם ה-child לא מזרים אף פעם, בדקו שתעבורת הבדיקה תואמת בדיוק לבוררים המוגדרים, כולל פרוטוקול ופורט. אם הוא מזרים ונכשל, קראו את שגיאת האימות או ההצעה במקום להסתיר אותה מאחורי לולאה אינסופית, כי keyingtries=0 יחזור בשמחה על דחייה קבועה לנצח.

טענו את השינוי בחלון ובדקו שוב

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

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

swanctl --load-conns
swanctl --list-conns

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