שתי זהויות בהתחברות IKEv2 אחת: קודם המכונה, אחר כך המשתמש

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

התסמין: כשל אחרי הוכחה ראשונה מוצלחת

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

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

מה ההרחבה מוסיפה ומה לא

IKEv2 נושא הרחבה לביצוע יותר מחליפין אימות אחד בתוך הפעלה אחת. RFC 4739 משרטט, בין שאר הרצפים, לקוח שמוכיח זהות של תעודה ואז מאמת אדם דרך EAP. המסמך הוא Experimental, כלומר שום מימוש לא חייב לכם את התכונה. אל תניחו דבר על תמיכה עד שהצד השני יתמקח עליה.

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

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

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

אותו קובץ נקרא אחרת בשער

אותו קובץ swanctl נקרא אחרת בהתאם למקום שבו הוא רץ, וזה החלק שמכשיל אנשים. במחשב הנייד השער הוא הצד השני, ובשער המחשב הנייד הוא הצד השני, ולכן כתבו את הצד local בתור מי אני ואת הצד remote בתור את מי אקבל. בלוק local מתאר כיצד הקצה הזה מאמת את עצמו, ובלוק remote מציין מה הוא דורש מהקצה השני. העתקת בלוק בין שני הקבצים הופכת את משמעותו בלי לשנות אף תו. השוואת שני הקבצים לא אומרת לכם כמעט כלום, כי לאותן מילים משמעות הפוכה בכל אחד מהם.

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

כלל הסדר הזה מייצר את אופן הכשל שראוי לזכור. בלוק remote שני אינו אפשרות מקובלת נוספת; הוא דרישה שנייה, ולכן מדיניות שנקראת כמו או/או מתנהגת כמו וגם-אז. מדיניות שער יכולה לקבל את התעודה של המכונה הרשומה ואז לדרוש את חילופי ה-EAP של אותו משתמש, בסדר הזה.

הבחינו בין סבבים לגורמים בלתי תלויים

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

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

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

כתבו את כלל הצימוד ובדקו את הדחיות

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

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

swanctl --list-conns
swanctl --list-sas

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