IKEv2 NO_PROPOSAL_CHOSEN: איזה שלב דחה את החבילה?

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

קודם: איזו החלפה נדחתה

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

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

השוו חבילות שלמות, לא מילות מפתח בודדות

הצעה היא שילוב: אלגוריתם הצפנה, שלמות או AEAD, קבוצת החלפת מפתחות וכל פונקציה פסאודו-אקראית. השוואה של שם ההצפנה בלבד היא הטעות הרגילה, כי שני עמיתים יכולים להסכים על AES-256 ועדיין לחלוק על SHA-1 מול SHA-256. כתבו את החבילות שהוצעו והמותרות זו לצד זו בשלב שנכשל, ואז חפשו את החיתוך הריק.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

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

חבילת IKE וחבילת ESP הן אובייקטים שונים

עריכת הצעת IKE לא תתקן הצעת CHILD שנדחתה, וגם ההפך נכון. ב-strongSwan אלה הגדרות נפרדות, בערך proposals = aes256-sha256-modp2048 עבור IKE SA ורשימת ESP נפרדת עבור CHILD SA. שנו את הרשימה שמתאימה להחלפה שנכשלה, ואז קראו שוב את היומן במקום להניח שהתיקון עבד.

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

מנהרה שעובדת ונכשלת בחידוש מפתח

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

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

ipsec statusall | grep -E "IKE:|ESP:"

בחרו חיתוך, ואז אשרו את שני השלבים

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

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