שגיאה אחת, שלושה סודות: איזה פרט זיהוי של VPN נכשל?
הלקוח מציג שגיאה אחת לכל שלב. קראו את השיוך, את חילופי המשתמש ואת השיטה לפני שמאפסים סיסמה שאף אחד לא בדק.
«האימות נכשל» יכול להצביע על תעודת שרת, על מפתח ששותף מראש של המכונה או על סיסמת משתמש. איזה מהם הוא מתכוון תלוי בפרוטוקול, כי כל פרוטוקול מגדיר קבוצה אחרת של סודות. אם תאפסו את הלא נכון, השגיאה תישאר ללא שינוי. הדרך החוצה היא לקבוע כמה הוכחות הפרוטוקול דורש לפני שמשנים משהו.
שתי הוכחות שמצביעות בכיוונים מנוגדים
מנהרה צריכה לענות אם היא הגיעה לכתובת השער הנכונה, ובנפרד מי הוא המשתמש. הוכחת השער היא ברמת המכונה: תעודת שרת, מפתח ששותף מראש או מפתח ציבורי סטטי. הוכחת המשתמש היא ברמת האדם: סיסמה, אסימון, תעודת לקוח, או כלום. אלה כיוונים מנוגדים של אמון והם צורכים חומר שונה.
IKEv2 מבצע את הוכחת השער בתוך IKE_AUTH, וכאשר משתמשים ב EAP הוא מריץ אחר כך את הוכחת המשתמש בחילופין נפרדים. מפרט IKEv2 שומר עליהם כסעיפים נפרדים, וזה רמז חזק היכן לחפש כשמסר אחד מכסה את שני הסבבים.
קראו את השלב, לא את ההודעה
הלקוח מציג מחרוזת שגיאה אחת לא משנה איזה שלב נכשל, ולכן המחרוזת עצמה כמעט לא נושאת מידע. מה שכן נושא מידע הוא המצב שאפשר לבדוק בכל שלב: אם קיים שיוך, אם החל חילופי משתמש ואם הלקוח הציע את השיטה שהשער רצה. הטבלה ממיינת את השלבים כך ולא לפי שם הפרוטוקול.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
רק השורה השנייה עוסקת בפרט זיהוי שמשתמש יכול להקליד מחדש. שלוש האחרות הן עובדות תצורה, ואי ההתאמה הזה הוא הסיבה לכך כל כך הרבה מהדיווחים האלה מסתיימים באיפוס סיסמה שלא משנה דבר. קראו את השורה שמתאימה לראיה שלכם לפני שנוגעים בשדה.
פרוטוקול עם שני סודות מראה את הקלפים
L2TP מעל IPsec הופך את המניין לגלוי, כי שתי הבדיקות מתרחשות בתהליכים שונים. שכבת IPsec חייבת לעלות תחילה עם מפתח ששותף מראש או עם תעודה, ורק אחר כך PPP שבתוכה מנסה כניסת משתמש.
כשסוד המכונה שגוי לא נוצר שיוך והפרטים של המשתמש לא נבדקים לעולם. כשסוד המכונה נכון וסוד המשתמש שגוי השיוך קיים ו PPP דוחה את הכניסה אחרי שהמנהרה כבר עלתה. שניהם מייצרים את אותה הודעה על המסך משני אירועים שונים.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerרשימת שיוכים ריקה מפילה מיד את שכבת המשתמש, לכן בדקו אותה לפני הסיסמה. שיוך קיים עם כשלי PPP חוזרים מצביע לכיוון השני, לשכבת המשתמש או לפרוטוקול האימות שבתוכה. אף אחת משתי המסקנות לא זמינה מטקסט השגיאה של הלקוח.
במה באמת תלוי חיבור עם סיסמה בלבד
גישה עם סיסמה בלבד היא שגרתית עבור L2TP, PPTP, SSTP ו IKEv2 עם EAP. ל WireGuard אין אפשרות כזו בכלל, כי העמיתים שלו הם מפתחות ולא משתמשים. ב OpenVPN התשובה מגיעה מדרישת תעודת הלקוח של השרת: שער שדורש גם תעודה וגם סיסמה ימשיך לדחות לקוח עם סיסמה בלבד, לא משנה מה יוקלד בשדה.
איזה רכיב דרוש לכם נובע מאותה תשובה. כניסה עם סיסמה תחת IKEv2 דורשת לקוח שמדבר EAP, ואילו כניסה עם תעודה זקוקה למפתח הפרטי של הלקוח ולשרשרת של השרת. אם תתקינו את הלא נכון, הכשל ייקרא כשגיאת פרטי זיהוי למרות ששיטת האימות עצמה היא החסרה.
שנו דבר אחד ואז בדקו שוב
קבעו תחילה שלוש עובדות: איזה פרוטוקול פועל, כמה סודות הוא מגדיר ואילו מהם שייכים למכונה ולא למשתמש. מכונות נכשלות בשלב הראשון ואנשים נכשלים בשני, וערבוב בין השניים הוא כל הבעיה הזו.
אחר כך שנו בדיוק דבר אחד ובדקו שוב מאותו לקוח. המשמעת הזו הופכת כשל מבלבל לתיקון שאפשר לתאר לאדם הבא, וזה שימושי יותר מחיבור שעובד ואף אחד לא יודע להסביר.