החלפת IKEv2 מצליחה, ואז האימות נכשל: היכן לחפש

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

בדיקה 1: קראו את השלב, לא את ההודעה

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

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

בדיקה 2: איזו זהות נבדקה

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

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

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

בדיקה 3: אם EAP מעורב

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

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

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

בדיקה 4: מה קורה אחרי התחברות מוצלחת

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

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

בדיקה 5: מה למסור לתמיכה

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

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