L2TP/IPsec נכשל: בידוד IPsec, אימות המנהרה או התחברות PPP

שלושה דברים מתאמתים בתוך חיבור L2TP/IPsec אחד, ורק אחד מהם נוגע לאדם שמחייג. IPsec מוכיח את קצות המנהרה, חיבור הבקרה של L2TP עשוי להוכיח שוב את העמיתים באמצעות סוד משלו, ו-PPP מוכיח לאחר מכן את חשבון המשתמש בתוך הסשן. כשל בכל שלב נראה כשגיאת התחברות כללית בתיבת הדו-שיח של הלקוח ונראה אחרת לגמרי ביומן השרת. עברו על השלבים לפי הסדר ועצרו בראשון שנכשל, כי כל שלב שמתחת לשלב שלא נבדק גם הוא לא נבדק.

שלושה שלבי אימות, שלוש זהויות שונות

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

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

RFC 2661 הופך את אימות חיבור הבקרה הזה לרשות, מה שמסביר מדוע אותה טעות מפיקה תסמינים שונים בשני שרתים. פריסה שמעולם לא הגדירה סוד מנהרה מדלגת על השלב כולו; פריסה שהגדירה אותו בצד אחד בלבד נכשלת לפני ש-PPP מוצע בכלל. לאחר מכן PPP מאמת את המשתמש עם PAP, CHAP או MSCHAPv2 ומעביר את השם למאגר חשבונות שעשוי להיות מקומי, ב-chap-secrets, או ב-RADIUS. סיסמה שגויה בשלב הזה עדיין משאירה אותך עם מנהרה עובדת וסשן שנכשל.

קראו את נקודת העצירה לפני עריכת קונפיגורציה

התחילו עם ipsec --version כדי לדעת אם פלט המצב שייך ל-strongSwan או ל-Libreswan. אחר כך קראו את יומן השרת, לא את תיבת הדו-שיח של הלקוח, כי השרת רושם איזה שלב סירב.

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

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

שלב ראשון: האם ל-IPsec יש אסוציאציה?

הריצו ipsec statusall ב-strongSwan או ipsec whack --status ב-Libreswan וחפשו אסוציאציית בת מבוססת עם מונים שאינם אפס. ip xfrm state מציג את תצוגת הקרנל בשניהם. זוג SAs מותקן עם מונים שעולים פירושו שהשלב הראשון הושלם וניתן להתקדם.

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

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

שלב שני: האם חיבור הבקרה של L2TP אימת?

לאחר ש-IPsec פועל, עקבו אחרי הדמון של L2TP אחר חיבור בקרה שמגיע למצב מבוסס, שכן PPP לא יכול להתחיל לפני כן. סירוב בחיבור הבקרה פירושו שסוד המנהרה שונה בין הקצוות, או שקצה אחד דורש סוד שהשני לעולם לא שולח. לקוחות מציגים לעיתים קרובות שדה אחד המסומן shared secret, והוא בדרך כלל שייך ל-IPsec ולא ל-L2TP. מילוי שלו לא מגדיר את סוד המנהרה, וניקוי שלו לא מנטרל אותו.

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

רק סשן שמתחיל לנהל משא ומתן על PPP באמת עבר את שלב המנהרה.

שלב שלישי: האם PPP דוחה את החשבון?

כשל PPP נראה אחרת מבחוץ: המנהרה מבוססת, הסשן מתחיל, והדמון רושם כשל בשיטת אימות או דחיית חשבון. קראו את השיטה הנקובה בהודעה הזו. PAP ו-CHAP נכשלים מסיבות שונות, ושרת שדוחה אחת מהן ידחה לקוח שמציע רק אותה.

בשרת לינוקס, בדקו את קובץ האפשרויות שהדמון מעביר ל-PPP, בדרך כלל /etc/ppp/options.xl2tpd, ואשרו אילו שיטות מתקבלות והיכן נפתרים חשבונות. שם שקיים ב-RADIUS אך לא בקובץ הסודות המקומי נכשל בצורה נקייה ונראה כמו סיסמה שגויה. לאחר מכן בדקו שהלקוח מציע שיטה שהשרת מקבל, ולא שיטה חזקה יותר שהשרת מסרב לנהל עליה משא ומתן. החלפת המפתח המשותף מראש כדי לתקן את השלב הזה מבזבזת אחר צהריים ולא משנה דבר.

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