GCP HA VPN דוחה את FortiGate: סוג ה-ID המקומי אינו תואם
Google משווה את הזהות ש-FortiGate מצהיר עליה, לא רק את המפתח המשותף מראש. ID מקומי מסוג FQDN נכשל בבדיקה הזו בזמן שהלוג עדיין אומר אימות.
AUTHENTICATION_FAILED מ-Google Cloud HA VPN בדרך כלל מחזיר אנשים למפתח המשותף מראש, והמפתח בדרך כלל תקין. המנהרה נתקעת בשלב 1 כי Google משווה גם משהו אחר: הזהות שהצד השני מצהיר עליה במהלך חילופי IKE. ב-FortiGate הזהות הזו יכולה להחליף סוג בלי שאף אחד יערוך כתובת. קראו את הלוג כאי-התאמת זהות לאחר שהמפתח הוזן שוב פעמיים.
כשל אחד, שתי בדיקות
IKE מאמת צד שני בשני שלבים נפרדים. המפתח המשותף מראש מוכיח ששני הקצוות מחזיקים באותו סוד, וזהות מוצהרת אומרת למגיב מי הצד השני טוען שהוא. Google בודק את הזהות הזו מול הצד השני שאיתו הוא הוגדר. אם משאירים אותו לבדו, FortiGate שולח זהות מבוססת כתובת שנגזרת מהממשק היוצא שלו, וההשוואה עוברת בלי שאף אחד שם לב.
שני השלבים נופלים לאותו דלי בלוג, מה שמסביר את הלולאה המוכרת של הקלדת המפתח מחדש ארבע פעמים לפני שמישהו קורא את מטען הזהות.
מה FortiGate מכניס למטען הזהות
הצרה מתחילה כשמישהו מגדיר ID מקומי כדי ששני הצדדים יסכימו. גרסאות FortiOS אחרונות מסמנות את הזהות הזו כשם תחום מלא גם כשהערך שהוקלד הוא כתובת עם נקודות. לכן Google מקבל זהות FQDN בעודו מצפה לכתובת, והוא דוחה את החיבור. דבר בהודעה לא אומר איזה חצי נכשל, ולכן הדוח נקרא ככשל אימות.
שחזרו זאת פעם אחת עם ניפוי IKE מופעל וקראו את מטען הזהות שהחומה באמת שולחת.
באותו מעבר, אשרו שלוש עובדות זולות: גרסת ה-IKE ששני הקצוות משתמשים בה, המפתח המדויק כולל תווים סופיים בלתי נראים, וכתובת הצד השני ש-Google מצפה לה. הן עונות על שאלות שונות, ומפתח תואם לא אומר דבר על הזהות.
אפשרויות, ומה כל אחת עולה
כל יציאה מתקנת שכבה אחרת, ואף אחת מהן אינה זמינה לכל פריסה.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
תיקון הזהות בחומה הוא התשובה הנקייה ביותר כשה-Firmware מאפשר לבחור את הסוג ולשמור על הערך. השדה קיים בגרסאות מסוימות וממלא את הסוג בטעות באחרות, ולכן בדקו את הגרסה שלכם במקום לסמוך על הערות מהדורה.
כתובת ציבורית ניתנת לניתוב בממשק המשא ומתן היא הפתרון המתועד, כי אז הזהות ברירת המחדל תואמת למה ש-Google מצפה לו ולא נדרש עקיפה. לשם מגיעות רוב הפריסות, אם החומה בכלל יכולה להחזיק כתובת כזו.
סיום על צד שני שמאמת את מה שאתם מייצרים הוא שינוי טופולוגיה. התייחסו לזה כהחלטת תכן ולא כפתרון עוקף עם תיאור ידידותי יותר.
כאשר NAT מסיר אפשרות אחת
מאחורי NAT יציאת הכתובת הציבורית נעלמת, ומה שנשאר תלוי בהתנהגות Firmware שאינכם שולטים בה. זו הנקודה לבחור במודע בין שדרוג, העברת הצד השני או קבלת נקודת קצה עננית אחרת. אלה שלושה תקציבים שונים, ובחירה באחד בטעות היא הדרך שבה פתרון עוקף זמני הופך לארכיטקטורה. כתבו את הבחירה ואת הסיבה שלה לצד המנהרה.
לפני פירוש של כל אחד מאלה, אשרו את מצב המנהרה בצד של Google ושהחבילה אינה נזרקת סתם בדרך. חבילה שנזרקה מסתיימת בפסק זמן; היא אינה יוצרת דחייה.
מה לתעד בזמן שזה עובד
רשמו את סוג הזהות, את ערכה, את גרסת ה-Firmware ואת כתובת הצד השני שהיו בתוקף כשהמנהרה עלתה לאחרונה. עדכון Firmware יכול לשנות שוב את ברירת המחדל, והכשל הבא ייראה בדיוק כמו אי-התאמת מפתח. כשהזהות שמורה לצד המפתח וכתובת הצד השני, האדם הבא מתחיל מהבדיקות הזולות.
התיעוד הזה הוא גם הדרך היחידה לדעת אם עדיין צריך פתרון עוקף אחרי השדרוג הבא.