IKEv2 ב-Windows וב-FortiGate: שלושה הגדרות שאנשים ממזגים
החלפת מפתחות IKE, הגנת CHILD SA ואימות העמית הם שלושה שורות נפרדים. מספרי קבוצה תואמים בשני חלונות אינם ממזגים אותם.
הסכם IKEv2 בין לקוח Windows לשער FortiGate ממשיך להיכשל, והחיפוש אחר מספר לא מתאים מייצר רשימה ארוכה אף יותר של מספרים. הרשימה נעשית ניתנת לניהול רק כאשר מפצלים אותה לשלושה שורות שנכשלות באופן עצמאי: החלפת המפתחות שמגנה על IKE, ההגנה שמוחלת על ה-CHILD SA, והאימות שמוכיח מי כל צד. מספרי קבוצה מופיעים בשניים מאותם שורות ומשמעותם שונה.
שלושה שורות שנכשלות באופן עצמאי
השורה הראשונה היא החלפת המפתחות בתוך IKE עצמו, שמייצרת את המפתחות שמגנים על המשא ומתן. השנייה היא ההצעה ל-CHILD SA, שמגנה על התעבורה שהמנהרה נושאת. השלישית היא האימות, שקובע מה כל צד מציג וכיצד הצד השני מאמת אותו.
כשלים מתרחשים במקומות שונים. כשל בהחלפה עוצר את המשא ומתן לפני שקיימת מנהרה. כשל ב-CHILD SA מתרחש לאחר שהאימות הצליח, לעיתים רק בחידוש מפתחות. כשל באימות יכול להיראות ביומנים כמו כשל בהחלפה אם קוראים רק את השגיאה הראשונה.
הפרדת השורות אינה הנהלת חשבונות. היא משנה איזה הגדרה שווה לשנות, והיא מונעת את המהלך היקר ביותר בכל התחום הזה, כלומר יצירה מחדש של תעודות עובדות כדי לתקן אי-התאמה בהצעה. שינוי של שורה אחת לא אמור לאלץ את שתי האחרות להשתנות איתה. העצמאות הזו היא כל הסיבה לכתוב אותן בנפרד.
מה שולטים שני השדות של Windows
Windows מחזיק שני שדות בנפרד: DHGroup מגדיר את החלפת IKE עצמה, ואילו PfsGroup מגדיר את מדיניות IPsec שמגנה על התעבורה במנהרה. הם שייכים לשלבים שונים. השוואה בין שדה IKE של Windows לערך שלב 2 של FortiGate בודקת את הזוג הלא נכון, והמספרים יכולים להתאים בעוד שההחלפה שמתחת נכשלת עדיין.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAהפקודה השנייה והשלישית מדווחות על אסוציאציות האבטחה שקיימות בפועל, וזה הדבר הקרוב ביותר לתשובה שלקוח יכול לתת לך. אסוציאציה במצב ראשי בלי אסוציאציה במצב מהיר היא בעיית CHILD SA, וזה הסימן לאי-התאמה בשלב 2 ולא לבעיית תעודה.
תעד מה הוצע ומה נבחר בניסיון אחד. רשימה מוצעת שמכילה הצעה קבילה והצעה נבחרת שאינה תואמת את מדיניות השער היא מחלוקת תצורה, לא תעלומת יכולת פעולה הדדית.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
קבוצת עקומה אליפטית אינה בוחרת את מפתח החתימה שלך
המסקנה השגויה העקשנית ביותר בתחום הזה היא שבחירת קבוצת DH של עקומה אליפטית מחייבת תעודת עקומה אליפטית. קבוצת DH מספקת חומר להחלפת מפתחות; אלגוריתם החתימה נקבע במשא ומתן על ידי מסגרת האימות, ואלה שני החלטות נפרדות ב-IKEv2.
RFC 7427 קיים בדיוק מפני שההחלטות האלה היו שזורות בעבר, והוא מגדיר כיצד אלגוריתמי חתימה מוכרזים ונבחרים באופן עצמאי מהחלפת המפתחות. שער יכול לתמוך בו-זמנית גם בקבוצת עקומה וגם במבחר של סכימות חתימה.
לכן כאשר משא ומתן נכשל לאחר שינוי קבוצה, הסתכל על שיטת האימות לפני שאתה מסתכל על סוג המפתח של התעודה. החלפת תעודה היא פעולה איטית ומסוכנת שכמעט אף פעם אינה התשובה, ועשייתה ראשונה הורסת את היכולת שלך לדעת איזה שינוי באמת עזר. קרא את שורת האימות לפני שאתה נוגע במאגר התעודות.
שמור את שניהם בשורות נפרדות של דף ההסכם והטעות תפסיק להיות מפתה. שורה אחת מפרטת קבוצות, השנייה מפרטת סכימות חתימה וזהויות, ואף אחת מהן אינה ראיה לגבי האחרת.
הצב כל מפתח פרטי אצל הבעלים האמיתי שלו
שער שמציג תעודה משלו זקוק למפתח הפרטי שמתאים לה. עמית שמאמת שרשרת זקוק לתעודת ה-CA, ובאופן ספציפי אינו זקוק למפתח החתימה של ה-CA. ערבוב שלושת הרכיבים האלה הוא הדרך שבה אנשים מגיעים לייבא מפתח פרטי של CA להתקן VPN כדי שתעודה תופיע בקטגוריה אחרת.
ב-FortiOS התפקידים נפרדים: תעודה מקומית עם המפתח שלה, תעודה מרוחקת שמשמשת לזיהוי עמית, ורשומת CA מרוחקת שמבססת אמון בתעודות שאותו CA חתם עליהן. רשומת CA מרוחקת בלי מפתח פרטי אינה חסרה; היא נכונה למטרתה.
מפתחות חתימה של CA שיובאו מרחיבים את הסמכות של כל מי שיכול לקרוא את ההתקן הזה. הם גם לא פותרים אימות עמית רגיל, כי אימות זקוק לתעודה הציבורית ולהחלטת האמון, לא ליכולת להנפיק תעודות חדשות.
שמור את מפתח החתימה של ה-CA אצל התהליך של המנפיק עצמו, ותעד איזה התקן מחזיק איזה מפתח. טבלה קצרה של בעלים שווה יותר מטבלה ארוכה יותר של אלגוריתמים כאשר ביקורת שואלת מי יכול היה להתחזות למי. אף אחד לא מייבא מפתח שהוא יודע שהוא רק למלאי. כתוב את המלאי לפני התקרית, לא אחריה.