מצב trap ב-strongSwan: מדוע מנהרת IPsec ממתינה לתעבורה

לא מופיע CHILD SA בפלט המצב, המנהרה נראית מתה, ואז פינג לתת-הרשת המרוחקת מעלה אותה. בהגדרת IPsec לפי דרישה הרצף הזה הוא התכנון, לא תקלה. מדיניות trap מתקינה בורר וממתינה, והחבילה הראשונה שמתאימה לה היא שמתחילה את IKE ואת משא ומתן ה-CHILD SA.

חלק מהבלבול הוא אוצר מילים: “up” משמש לשני מצבים שונים. התצורה נטענה ומדיניות הליבה קיימת, אבל התאחדות הנתונים לא. מוניטור שסופר רק SA פעילים ידווח על אתר בריא כנמוך כל עוד אף אחד לא שולח אליו תעבורה.

למנהרה לא פעילה לפי דרישה אין CHILD SA להציג

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

הסדר הזה הוא מה שהופך את הלוגים לקריאים. קודם מגיע ה-acquisition, אחר כך IKE_SA_INIT ו-IKE_AUTH, ואז ה-CHILD SA. אם הלוג נגמר מיד אחרי ה-acquisition, ההדק עבד. המשא ומתן נכשל, והשאלה הבאה היא על אישורים, הצעות או נגישות, לא על ה-trap.

עם backend הליבה של Linux אפשר לראות את המדיניות לפני שקיים SA כלשהו. הריצו ip xfrm policy וחפשו את הבורר עם כיוון out ותבנית שמצביעה על החיבור. הרשומה הזו היא מצב לפי דרישה, והנוכחות שלה היא הדבר הראשון שצריך לאשר.

start_action קובע אם בכלל משהו ממתין

כל child ב-swanctl.conf נושא start_action. start מתחיל כשהתצורה נטענת, trap מתקין את המדיניות וממתין, ו-none משאיר את ההתחלה למשהו אחר. רק trap מפיק את התנהגות “פינג והוא עולה” שתוארה למעלה.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

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

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

גלו אם ההדק הופעל בכלל

התחילו עם swanctl --list-conns ואשרו שה-child נטען עם הפעולה שהתכוונתם. אחר כך שלחו חבילה אחת ממארח בתוך local_ts לכתובת בתוך remote_ts וצפו ב-swanctl --list-sas. אם הפלט לא משתנה, שום acquisition לא הגיע לדמון.

שתי סיבות נפוצות ל-trap שקט: החבילה עברה source-NAT לפני שפגעה במדיניות ואינה מתאימה עוד ל-local_ts, או שהחיבור מעולם לא נטען בגלל שגיאת תחביר או אישורים. הריצו שוב swanctl --load-all וקראו את הפלט לפני שנוגעים בבוררים. חיבור שלא נטען לא מתקין שום מדיניות, כך שאין דבר שהתעבורה תפעיל.

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

המתנה לחבילה הראשונה היא לא תמיד העסקה הנכונה

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

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

גם מדיניות מותקנת אינה ערובה אטומה לדליפות. אם הדרישה היא fail-closed, חומת האש חייבת להפיל תעבורה בלי SA, והכלל הזה חי מחוץ להגדרת ה-child.

רשמו את שלושת השורות שמסיימות את הוויכוח הבא

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

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