סוד משותף או התחברות משתמש: איזה שדה ב-L2TP/IPsec נכשל?
מפתח משותף מראש מוכיח את העמית, בעוד ששם המשתמש והסיסמה של PPP מוכיחים את האדם. קוד השגיאה אומר איזו משתי השכבות נשברה.
משרד אחד יכול להעביר את אותו סוד IPsec לכל מחשב נייד בעוד כל אדם נכנס עם חשבון אישי, ולכן «המפתח נכון» ו«הסיסמה נכונה» יכולים להיות נכונים שניהם וההתחברות בכל זאת להיכשל. L2TP ו-IPsec מאמתים צדדים שונים בשלבים שונים. השוואה בין שתי השכבות, וקוד השגיאה שמפריד ביניהן, סוגרים את רוב הפניות האלה מהר יותר מאשר החלפה נוספת של שני הערכים. השלבים אינם ניתנים להחלפה, וההודעה שלפניכם כבר אומרת איזה מהם פעיל.
שתי שכבות, שתי זהויות שונות
אימות העמית של IPsec רץ ראשון. הלקוח והשער מוכיחים זה לזה מי הם, באמצעות מפתח משותף מראש או תעודה, לפני שכל מטען של מנהרה מוגן. החלפת PPP בתוך הפעלת L2TP מגיעה אחר כך, ושם שם המשתמש והסיסמה שלכם נבדקים מול מאגר החשבונות של השרת.
השלבים בלתי תלויים, לכן חשבון משתמש תקף אינו יכול להציל מפתח IPsec שגוי, ומפתח נכון אינו יכול להציל סיסמה שפגה. כתבו את השניים בנפרד בפנייה, והאבחון בדרך כלל נובע מהשורה הראשונה ביומן שמציינת שלב.
| Observed failure | Stage that rejected it | Field to touch |
|---|---|---|
| Security layer error 789 during initial negotiation | IKE and IPsec peer authentication | The pre-shared key or the certificate |
| Error 691, credentials not recognised | PPP user authentication | User name, password, or account policy |
| Tunnel forms, then drops on the first packet | Neither, usually routing or MTU | Address pool and interface configuration |
| Prompt repeats with no error text | Often the client type selection | The connection profile, not the secret |
הסוד המשותף מוכיח את העמית
מפתח משותף מראש הוא אישור קבוצתי שנמצא בשער ובכל לקוח שמתחבר אליו. הוא מבסס שהעמית יודע את המפתח, וממנו IKE גוזר את המפתחות שמגנים על החיבור. שום דבר בהחלפה הזו אינו מזהה את האדם במקלדת. זו הסיבה כולה שקיימת התחברות שנייה, ברמת משתמש, באותה מנהרה.
לעיצוב הזה יש השלכה מעשית לביטול. אובדן מחשב נייד אחד פירושו סיבוב הסוד לכל מכשיר שמשתמש בו, אלא אם הפריסה עוברת לתעודות, שם אפשר להסיר מכשיר אחד בלי לגעת בשאר. העסקה היא מאמץ מנהלי מול רדיוס הנזק.
מפתח שמוקלד בפרופיל הוא גם האישור הקל ביותר לדליפה דרך צילומי מסך וצ'אט. התייחסו אליו כאל חומר תשתית משותף ולא כאל סיסמה אישית, כי בדיוק זה מה שהוא.
ההתחברות שייכת ל-PPP
בתוך הפעלת L2TP, PPP מנהל משא ומתן על אימות ומבקש מהשרת לאמת את צמד הערכים שהקלדתם. ב-Windows אלה אותו שם משתמש ואותה סיסמה שהפרופיל מבקש, ובנתב זה מה שפרופיל PPP מפנה אליו. זה נבדק מול מאגר החשבונות, לא מול המפתח. שני אנשים יכולים לחלוק מחשב נייד ומפתח ובכל זאת להיות מובחנים בשלב הזה.
מכיוון שזה אימות משתמש, חלות כל מדיניות החשבון הרגילה: סיסמה שפגה, חשבון נעול, הרשאת חיוג, או שם שחייב לשאת דומיין. שגיאה 691 מדווחת על השילוב הזה כנדחה, לכן קראו את רשומת החשבונאות של השרת לפני שתקלידו משהו מחדש.
תנו לשגיאה לבחור את השדה
שגיאה 789 מציינת את שכבת האבטחה ומצביעה על שלב IPsec. ודאו שהמפתח המשותף מראש בשני הצדדים תואם בדיוק, שזהות העמית שהשער מצפה לה תואמת את מה שהלקוח שולח, ושהלקוח מוגדר ל-L2TP/IPsec ולא לסוג אחר.
שגיאה 691 מציינת אישורים ומצביעה על PPP. בדקו את מצב החשבון ואת תבנית השם המדויקת לפני שתשנו את הסוד, כי שינוי שניהם בבת אחת הורס את הראיה שקראתם.
כשהמנהרה עולה והתעבורה עדיין נעצרת, הפסיקו לגמרי לערוך שדות אימות. הסתכלו על מאגר הכתובות, המסלול חזרה לתת-הרשת של הלקוח וה-MTU: השוואה בין שתי השכבות עוזרת רק כל עוד התקלה עדיין בתוכן.