FortiGate Azure החלפת מפתח: הצעת peer SA אינה תואמת למדיניות המקומית
מנהרת IKEv2 עובדת עדיין עשויה לדחות את ה-CHILD SA החלופי. השוו את ההצעה שהחידוש באמת מנהל משא ומתן עליה, לא זו שהשתמש בה ה-ping הראשון.
המנהרה עלתה, התעבורה זרמה, ומאוחר יותר היומן אומר peer SA proposal not match local policy. רוב האנשים קוראים את השורה הזו כהוכחה ששתי התצורות מעולם לא התאימו. בדרך כלל היא אומרת משהו צר יותר: הן התאימו עבור ה-CHILD SA הראשון והפסיקו להתאים בחידוש הראשון, מפני שהשיוך הראשון מעולם לא נזקק להחלפה שהשיוכים המאוחרים מבצעים. ההבחנה הזו קובעת היכן לחפש.
ה-CHILD SA הראשון יורש, המאוחרים מנהלים משא ומתן
ב-IKEv2 ה-CHILD SA הראשוני נוצר במהלך IKE_AUTH, והמפתחות שלו נגזרים מחומר המפתחות של ה-IKE SA. באותה נקודה אין החלפת Diffie-Hellman נפרדת, ולכן קבוצת PFS שאחד ה-peers אינו יכול לקבל פשוט עדיין לא נבדקת. המנהרה נראית בריאה מפני שהדרישה שתיכשל בה מאוחר יותר מעולם לא נבדקה.
חידוש מפתח של CHILD_SA הוא רצף הודעות אחר. כאשר PFS מוגדר, ה-peers מבצעים החלפת מפתחות חדשה וחייבים להסכים על קבוצה ששני הצדדים מקבלים, ועל הצעת ESP לשיוך החדש. זה הרגע שבו אי-ההתאמה נעשית גלויה, ולכן השגיאה מציינת הצעה ולא נתיב.
אז “זה עבד אתמול” לא אומר לך דבר על ההצעה. הוא אומר שההחלפה הראשונית הצליחה, מה שכבר ידעת.
קראו את ההחלפה שנכשלה, לא את ה-ping הראשון
אספו את אימות ה-IKE המוצלח, את ה-CHILD SA הראשוני ואת החלופה שנכשלה משני הקצוות לפני שתשנו משהו. אחר כך תנו שם מדויק לפעולה: חידוש מפתח של IKE SA, אימות מחדש של IKE וחידוש מפתח של CHILD SA הם שלושה אירועים שונים, ו“שלב 2” מכסה את כולם בשיחה רגילה.
השוו את השדות שלמטה עבור החיבור שנכשל, לא עבור המנהרה בכלל.
| שכבה | ערכים להשוואה |
|---|---|
| IKE | גרסה, הצפנה ושלמות או סידור PRF, קבוצת DH |
| IPsec / CHILD | הצפנה ושלמות של ESP, קבוצת PFS או החלפת מפתחות מיועדת |
| תעבורה מוגנת | בוררים מקומיים ומרוחקים, וכן כל הגדרת בורר מבוססת מדיניות |
ב-FortiGate, פתחו את הצעת שלב-2, את הגדרת ה-PFS ואת קבוצות ה-DH המקובלות עבור המנהרה הזו. קראו את הערכים הטעונים במקום להסיק אותם מחיבור שהוקם קודם. צילום מסך של עמוד ה-GUI הוא ראיה חלשה יותר מהתצורה הפועלת, מפני ששניהם יכולים לחלוק לאחר שדרוג. ייצאו את הקטע ששיניתם ושמרו אותו עם הכרטיס.
מדיניות ברירת המחדל של Azure היא עדיין מדיניות
היעדר מדיניות מותאמת שמחוברת לחיבור אינו אומר ש-Azure לא מחילה אף אחת. החיבור נופל חזרה למערך ההצעות המוגדר כברירת מחדל של השער, שעשוי להיות רחב או צר יותר ממה שה-FortiGate שלכם מציע. אם שתי הקבוצות חופפות עבור IKE אבל לא עבור ESP עם PFS, תקבלו בדיוק את דפוס הכשל הזה.
תצוגה זו לקריאה בלבד מראה את המדיניות שמחוברת בפועל, בלי לחשוף סודות:
Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPoliciesהשתמשו בשמות המשאבים האמיתיים שלכם. כשנדרשת מדיניות מפורשת, הגדירו אותה במשאב החיבור. זה אינו מתג ברמת השער, והוא אינו חל בשקט על מנהרות אחרות באותו שער.
בפורטל, עמוד Configuration של אותו חיבור הוא המקום שאליו הולכת מדיניות IPsec/IKE מותאמת. המדריך של Microsoft למדיניות מותאמת מפרט את הפרמטרים הנתמכים ואת דרישות ה-SKU. Azure לוקחת שילוב מלא אחד לכל חיבור, ולכן מציינים את שדות ה-IKE ואת שדות ה-IPsec יחד, לא אחד בכל פעם.
PFS הוא דרישה, לא מתג להפיכה
אם קו הבסיס האבטחתי שלכם דורש PFS, הפתרון הוא קבוצה ששני ה-peers מקבלים משני הצדדים, המבוטאת באמצעות מדיניות תואמת. כיבוי PFS כדי שהשגיאה תיעלם משנה את תכונת האבטחה שביקשתם לשמור, והיא בדרך כלל מופיעה שוב מאוחר יותר כאי-התאמה אחרת.
מלכודת אחת ייחודית ל-Azure: כשאתם בוחרים GCM עבור ESP, בחירות ההצפנה והשלמות חייבות לציין את אותו אלגוריתם GCM ואותו אורך מפתח. ערבוב צופן GCM עם אלגוריתם שלמות נפרד יוצר שילוב שהשירות דוחה, וזה נראה כמו אי-התאמה בין peers עד שתקראו את המדיניות בעיון.
בחרו את השילוב החזק ביותר ששני הקצוות תומכים בו ושהדרישה שלכם מאפשרת, ואז כתבו אותו ביומן השינויים. האדם הבא ישווה לאותו יומן, לא לזיכרון של מנהרה שעבדה. הכניסו לשם את קבוצת ה-PFS ואת הצעת ה-ESP, לא רק את שם המדיניות. כשמישהו ישאל מאוחר יותר למה ביקורת נכשלה או למה חידוש מפתח איטי, השורה הזו עונה על שתי השאלות.
ודאו את ההחלפה שנכשלה
תכננו את השינוי עם נתיב התאוששות, מפני שעריכת המדיניות עלולה לקטוע את המנהרה שאתם מנסים לתקן. אחרי שהתעבורה חוזרת, המתינו לחידוש CHILD_SA או הפעילו אותו, וודאו שהשיוך החדש נוצר עם קבוצת ה-PFS המיועדת. אחר כך ודאו שתעבורת היישומים ממשיכה דרכו.
שני מסלולי שווא ראויים לציון. משכי החיים של SA הם מפרטים מקומיים, ולכן ערכים לא שווים הם נורמליים ושינוים רק מזיז מתי הבעיה מופיעה. DPD מזהה אם peer חי; העלאת מסגרת הזמן שלו אינה מיישרת את בחירות ה-ESP או ה-PFS.
תעדו את התוצאה המסוכמת ואת האירוע הבא אחרי השינוי. אם החיבור נכשל כעת לפני שאימות ה-IKE מסתיים, אתם מסתכלים על הגדרות ה-IKE שזה עתה ערכתם, לא על כשל חידוש ה-CHILD המקורי.