למה מנהרת ה-IPsec שלך עובדת עד החלפת המפתח הראשונה של CHILD SA

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

מחובר לא אומר שהגדרות PFS תואמות

ב-IKEv2, אגודת הילד הראשונה נוצרת במהלך חילופי האימות, והמפתחות שלה נגזרים מחומר שאגודת ה-IKE כבר הפיקה. לא מתרחש חילופי Diffie-Hellman נפרד עבור אותו ילד, ולכן מדיניות שדורשת כזה בחידוש אינה נבחנת בעת ההעלאה.

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

היכן מסתתרת אי-ההתאמה במחרוזת ההצעה

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

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

קראו את הכשל, לא את הקובץ שערכתם

מצאו את ה-notify שסיים את החילוף. חידוש מפתח של ילד שמחזיר «אין הצעה מקובלת» מצביע על רשימות ההצעות; בקשת חידוש שלעולם אינה מקבלת תשובה מצביעה על הנתיב או על עמית שהפסיק להאזין. שני אלה דורשים תיקונים שונים, ונוסח שורת הלוג מפריד ביניהם.

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

שלושה אירועים שכולם נקראים החלפת מפתח

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

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

כיבוי החידוש אינו תיקון

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

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

הוכיחו את זה עם החילוף שנכשל

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

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