strongSwan EAP: זהות IKE מול שם ה-AAA הצפוי

לקוח strongSwan EAP יכול לאמת שני שמות שרת. remote.id מכסה את שער ה-IKE ו-local.aaa_id מכסה את שרת ה-EAP; אלה אינם שדה אחד.

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

חיבור אחד, שתי זהויות שרת

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

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

שני השמות מגיעים מתצורת המפעיל, ולא מהתעודה שמעלימה את השגיאה. לשאול את המפעיל על פרטי הפריסה מהיר יותר מלנחש שני שמות מארח.

איזה שדה שייך לאיזו שכבה

ב-swanctl הכתובת וזהות ה-IKE הן הגדרות נפרדות, וזהות ה-EAP היא שלישית.

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

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

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

מדוע aaa_id חי תחת local

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

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

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

ממשקים קדמיים שאינם יכולים לבטא את הפיצול

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

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

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

הבחן בין אי-התאמת זהות לבין תעודה שפגה

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

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

מאמרים קשורים