איך אימות היברידי של IKEv1 עובר לאימות משתמשים ב-IKEv2
המצב ההיברידי הפריד בין הוכחת השער להוכחת המשתמש. המעבר ל-IKEv2 שומר על ההפרדה הזו, אבל משנה את החליפין, את שיטת EAP ואת בדיקות התעודה.
כל פרופיל VPN ישן שמבקש תחילה תעודת שרת ואחר כך שם משתמש נושא שני אירועי אימות בחליפין אחד, והצורה הזו שורדת את הפרוטוקול שהכניס אותה. המצב ההיברידי של IKEv1 נבנה בדיוק לזה: השער מוכיח את עצמו במפתח ציבורי והמשתמש מוכיח את עצמו מאוחר יותר דרך XAuth. IKEv2 מבטא את אותו רעיון דו-שלבי במנגנון אחר, ובהבדלים האלה נכשלות ההעברות. שום מספר גרסה לא ממיר אחד לשני, והעתקת שמות האפשרויות הישנים לפרופיל חדש נותנת לקוח שמנהל משא ומתן ואחר כך לא מאמת דבר.
מה עשה המצב ההיברידי בתוך IKEv1
בפרופיל היברידי החותם על חליפין השלב הראשון הוא המשיב, עם התעודה שלו, ואילו היוזם אינו מציג תעודה כלל בכוונה. הוכחת הזהות היא אפוא אסימטרית, וזה מה שאיפשר לשער לשמור על ה-PKI הקיים בעוד המשתמשים שמרו על סיסמאות הספרייה. כשהשלב הראשון מסתיים, XAuth רץ כבקשה ותשובה שנושאות את מאפייני שם המשתמש והסיסמה בתוך ערוץ ISAKMP המוצפן כבר.
שימו לב היכן נוחתת האמון. התעודה עונה לאיזה שער הגיע הלקוח; XAuth עונה איזה משתמש רוצה גישה. אף אחד מהם לא מחליף את השני, ולקוח שמוגדר לקבל כל תעודת שרת ויתר בשקט על התשובה הראשונה. התווית היברידי משמשת גם למצב אגרסיבי עם מפתח משותף מראש ועוד XAuth, סידור אחר עם אותה חוויית משתמש, ולכן קראו את הפרופיל ולא את השם. שתי הגרסאות באות מטיוטות שמעולם לא הפכו לתקנים, ולכן שני יצרנים יכולים לממש מצב היברידי ולא לתקשר עם אף אחד.
איך IKEv2 מגיע לאותן שתי הוכחות
IKEv2 מחלק את העבודה בין IKE_SA_INIT ל-IKE_AUTH. החליפין הראשון מסכים על הצעות ומפתחות בלי שום זהות; השני נושא IDi, IDr ואת מטעני AUTH. תחת EAP מטען ה-AUTH הראשון של היוזם יוצא ריק, המשיב מאמת את עצמו ראשון עם התעודה והחתימה שלו, ואחר כך שיחת EAP מתנהלת בתוך הודעות IKE_AUTH.
המנגנון שעושה את זה בטוח הוא חומר מפתח. שיטת EAP מוצלחת מייצאת מפתח סשן, ומטען ה-AUTH האחרון של היוזם מחושב ממנו, כך שהוכחת המשתמש והמפתחות של המנהרה קשורים זה לזה. ל-XAuth אין מקבילה: המאפיינים שלו מגיעים אחרי השלב הראשון ולא תורמים דבר למפתחות. בדיוק את הפער הזה נועד מסגרת IKEv2 לסגור, ולכן התחברות IKEv2 עובדת מאמתת את תעודת השרת לפני שהיא מבקשת משהו.
הסדר הזה הוא גם אבחון שימושי. כשלקוח מתלונן על פרטי התחברות לפני שהראה לכם תעודה, הוא בכלל לא מבצע חליפין EAP של IKEv2.
הפרידו בין שלוש זהויות
העברה משתבשת כששלוש זהויות מתמוטטות לשדה אחד. יש את זהות השער שהלקוח מאמת, בדרך כלל שם DNS ב-subject או ב-SAN של התעודה. יש את זהות המשתמש שמוצגת ב-EAP, אולי התחברות לדומיין, כתובת או מחרוזת זהות EAP מפורשת. ויש את מקור ההרשאה שממפה את המשתמש הזה לרשתות ולמסלולים.
התחביר swanctl של strongSwan הופך את ההפרדה לגלויה: החיבור מגדיר remote { auth = pubkey } לשער ו-local { auth = eap-mschapv2 } למשתמש, כשזהות EAP מועברת בנפרד.
כשזהות המשתמש בפרופיל החדש שונה ממאפייני ה-XAuth הישנים, למשל UPN במקום שם קצר, שרת האימות רואה משתמש לא מוכר והכשל נראה כמו סיסמה שגויה. בדקו את מחרוזת הזהות לפני שבדקתם את פרטי ההתחברות.
מפו את האפשרויות ואז צפו למלכודות
המיפוי קצר ולכל שורה יש מלכודת שמופיעה רק בזמן האימות.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
אף אחת מהשורות האלה אינה שינוי שם בלבד. מטען התצורה מספק כתובות ופותרות דרך רשימת מאפיינים טיפוסית, בעוד שמרחב המאפיינים של XAuth היה המצאה משלו; להתייחס אליהם כאל ניתנים להחלפה הוא הדרך שבה פרופיל מבקש בסופו של דבר הגדרה שהשער לעולם לא ישלח.
בוררי התעבורה ראויים לאזהרה משלהם. IKEv1 ביטא תעבורה מעניינת דרך מזהי proxy הקשורים לחליפין quick mode, ואילו IKEv2 מנהל משא ומתן על הבוררים במהלך IKE_AUTH והמשיב רשאי לצמצם אותם. אי-התאמה מייצרת IKE SA מוקם בלי child SA, שיש לקוחות שמציגים אותו בשמחה כמחובר.
התייחסו לחיבור הישן כאל גבול
RFC 9395 מגדיר את IKEv1 כמיושן, ולכן חיבור היברידי ישן הוא גבול תאימות עם תאריך, לא יסוד. הריצו את שני הפרופילים זה לצד זה במהלך השינוי, כי המבחן שחשוב אינו אם הפרופיל החדש עולה אלא אם אותו משתמש באותו מכשיר מגיע לאותם משאבים.
שמרו על אימות תעודות קפדני לאורך כל הדרך. ברגע שהלקוח מפסיק להציג תעודה משלו, הפיתוי הוא להרפות מבדיקת השרת עד שהלחיצה תסתיים, וזה מחליף את ההוכחה היחידה שנותרה בסמל ירוק.
רשמו ארבעה דברים לפני שתפסיקו את הפרופיל הישן: שיטת EAP, מחרוזת הזהות, מקור ההרשאה והתאריך שבו התמיכה נגמרת.