פרופיל strongSwan טעון אינו מנהרה פעילה
strongSwan טוען הגדרות ואז מנהל משא ומתן על SA של IKE ו-CHILD. העובדה שפרופיל טעון לא אומרת דבר על קיומה של מנהרה או על מי שמפעיל אותה.
רישום חיבור בתצורת strongSwan מוכיח רק שהגדרה נטענה. זה לא אומר שיצרו קשר עם העמית, שקיים SA של IKE או שתעבורה כלשהי מוגנת. הדמון מתייחס להגדרות ולאסוציאציות חיות כאל אובייקטים נפרדים, והמרחק ביניהם הוא בחירת תכנון מכוונת. הידיעה איזה אובייקט אתם בודקים הופכת תקלה מעורפלת לפקודה הבאה מדויקת.
טעינה אינה חיבור
חיבור טעון הוא הצהרה על מה ניתן יהיה לנהל משא ומתן בהמשך: כתובות העמית, פרטי זיהוי, הצעות ובוחרי תעבורה. שום דבר בהצהרה הזו לא מחייב שהדמון התקשר למישהו. שער יכול להמתין לצד השני, ליזום בעת האתחול או להמתין שתעבורה מתאימה תעיר אותו. שלושתם תקפים, ושלושתם נראים זהים בקובץ התצורה עד שתקראו את מדיניות האתחול.
מפעילים נקלעים לצרות כשהם קוראים את רשימת ההגדרות כרשימת מצב. הפרופיל קיים, ולכן מניחים שהמנהרה פעילה, והשעה הבאה הולכת לניפוי שגיאות בנתיבים עבור אסוציאציה שמעולם לא נבנתה.
הטעות ההפוכה נפוצה באותה מידה. פרופיל חסר שולח אנשים לחפש תקלת רשת כשהתצורה מעולם לא נטענה. תנו שם לאובייקט ואז הריצו את הפקודה שמתבוננת בו.
שלושה אובייקטים, שלוש תצפיות
strongSwan מחזיק הגדרה טעונה, SA של IKE ו-SA של CHILD. הראשונה היא תצורה, השנייה היא יחס בקרה מאומת והשלישית היא הגנה מנוהלת עבור התעבורה הנבחרת. יש להם אפילו שמות נפרדים, כך שפרופיל בשם hq יכול להחזיק child בשם hq-lan.
הטבלה משייכת כל שכבה לפקודה שמציגה אותה. קראו את השורה לפני קריאת היומן.
| Layer | What it contains | Command |
|---|---|---|
| Definition | Peer addresses, credentials, proposals, and traffic selectors | swanctl --list-conns |
| IKE SA | One authenticated control channel to the peer | swanctl --list-sas |
| CHILD SA | Keys and selectors for the traffic being protected | Child rows under the IKE SA |
בקשת ה-child בונה תחילה את SA האב של IKE כשאין כזו. בקשה של SA של IKE בלבד היא קריאה אחרת. ערוץ בקרה שמאמת כראוי אינו מבטיח את ה-child שביקשתם.
ההבדל הזה חשוב בזמן כשל חלקי. SA של IKE יכול להיות בריא בעוד ה-child נכשל בגלל אי-התאמת בוחר או הצעה שהעמית אינו מקבל. שני האובייקטים נכשלים מסיבות שונות, ולכן מגיעות להם תצפיות נפרדות.
בחרו את פעולת האתחול במכוון
בקובץ swanctl.conf, השדה start_action של child קובע את ההתנהגות לאחר הטעינה. ברירת המחדל none משאירה את ההגדרה לאתחול ידני או לשימוש כ-responder. start מחייג אותה, בעוד trap משאיר מדיניות שמנהלת משא ומתן ברגע שמופיעה תעבורה מתאימה.
לכן גם «טעינה לעולם אינה מפעילה מנהרה» וגם «טעינה תמיד מפעילה אחת» שגויים. הפעולה היא חלק מהפרופיל והיא צריכה להתאים לתפקיד העמית. שני שערים ששניהם ממתינים לצד השני מייצרים שקט, לא מנהרה.
עם trap התעבורה חייבת להתאים לבוחרים, ולכן פינג לא קשור לא יעיר דבר. עם start כתובת העמית חייבת להיות שמישה ושני הצדדים חייבים להסכים על אימות והצעות. אף אחת מהפעולות אינה מחליפה את בדיקת התנאים האלה.
שחזור הוא מדיניות נפרדת
אתחול אינו keepalive. זיהוי עמית מת, סגירה מפורשת מצד העמית, חידוש מפתחות והפעלה מחדש של התהליך הם אירועי מחזור חיים שונים עם הגדרות משלהם. הגדירו כל אחד מהם במכוון במקום לצפות שאתחול ראשוני יכסה את כולם.
מנהרה שעולה באתחול ומתה כעבור שעה היא שאלת שחזור. מדיניות האתחול עשתה את שלה ואז הפסיקה להיות חשובה. הביטו בהגדרות DPD וחידוש המפתחות לפני שאתם מאשימים את המשא ומתן הראשוני.
החלפת הגדרות טעונות היא פעולה בפני עצמה. למדיניות אתחול שאינה ברירת מחדל יש פעולות הפוכות מתועדות, וטעינה מחדש היא שינוי תפעולי ולא הנחה שכל אסוציאציה עודכנה במקום. בצעו טעינות מחדש בשלבים שבהם חיבור מחדש מקובל. שמרו את התצורה הישנה עד שהחדשה תוכח.
בדקו מה קיים לפני שאתם מנפים שגיאות בניתוב
בצעו את שלוש התצפיות לפי הסדר: הגדרות טעונות, SA פעילים של IKE ורשומות child. כל תשובה מצמצמת את השאלה הבאה. דלגו על שלב ובסוף תנפו שגיאות בשכבה שמעולם לא נבנתה.
התחילו ממה שטעון ומה שבאמת מבוסס:
swanctl --list-conns
swanctl --list-sasאם ה-child חסר והפרופיל תקין, הפעילו אותו בשמו וצפו במה שקורה. הפלט בדרך כלל אומר אם האב עלה ראשון.
swanctl --initiate --child hq-lanSA פעיל של CHILD אינו קו הסיום. כללי העברה, נתיבים וההרשאה של היישום עצמו עדיין חייבים להסתדר. מחזור החיים עונה מה נוהל במשא ומתן; הוא לא יכול להחליט מי רשאי להשתמש בשירות.