התעודה של השער תקינה: למה הכניסה ב-IKEv2 PEAP עדיין נכשלת

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

שתי זהויות, ניסיון כניסה אחד

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

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

קראו את שורת הלוג מול השלב

מצאו את ההודעה שמציינת את הסיבה ואת התאריכים. תלונה על מרווח תוקף לצד שגיאת נושא פירושה שהשרת דחה את התעודה שקיבל, ולא שהמשתמש דחה את הכניסה. לאחר מכן מצאו את השלב: לוג charon של strongSwan מציג IKE_SA .* established לפני שחילופי EAP מתחילים, ולכן שגיאת תעודה אחרי השורה הזו שייכת לזהות EAP, בעוד שגיאה לפניה מצביעה על השער. טקסט השלב בחלון החיבור של לקוח Windows אומר את אותו דבר.

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

מצאו איזו נקודת קצה מסיימת את PEAP

בתכנון של שער יחד עם RADIUS, השער מעביר את EAP ואינו מסיים אותו. תוסף eap-radius של strongSwan מעביר את החילופים לשרת ה-RADIUS, שבבעלותו סשן ה-TLS של PEAP והתעודה שלו. הצליבו ניסיון כושל אחד בשני הלוגים ואשרו איזה תהליך בחר בפועל תעודה לאותו סשן.

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

החליפו את התעודה במקום שבו EAP מסתיים

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

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

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

מה לא לעשות

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

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