L2TP NO_PROPOSAL_CHOSEN: איזה שלב באמת נכשל?
ההודעה אומרת שהצעה נדחתה, לא איזו. קראו את יומן ה-backend כדי לזהות את השלב, ואז השוו את החבילות עם מי שמפעיל את השער.
NO_PROPOSAL_CHOSEN מגיע לפני שנבדק כל שם משתמש PPP, וזו עובדה שימושית וגם הסיבה שההודעה מטעה. היא מדווחת שצד אחד דחה הצעה; היא אינה מדווחת איזה פרמטר לא התאים, ואינה אומרת דבר על האם הדחייה התרחשה בזמן בניית שיוך ה-IKE או מאוחר יותר בזמן המשא ומתן על הגנת התעבורה. מאחורי שתי האפשרויות האלה עומדים שני תיקונים שונים, ורק אחד מהם נוגע בתיבת הסימון PFS שאליה פונים קודם.
הודעה אחת, שתי קבוצות הצעות
לסידור IKEv1 L2TP/IPsec יש שני משאים ומתנים ברצף. שלב 1 בונה את שיוך האבטחה של IKE מאלגוריתם הצפנה, אלגוריתם שלמות וקבוצת Diffie-Hellman. שלב 2 מנהל משא ומתן על איך התעבורה מוגנת, ודרישת PFS שייכת לאותה שיחה שנייה.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
מכיוון שהשלבים עוקבים, מקום הכשל אומר לכם איזו רשימה להשוות. זה כל הערך האבחוני שבהודעה, וכדאי לחלץ אותו לפני שנוגעים בהגדרה.
למה תיבת סימון PFS לא יכולה לתקן את שלב 1
כיבוי PFS משנה תכונה של שלב 2. אם הצדדים מעולם לא הסכימו על שלב 1, שיחת ה-ESP כלל לא מתקיימת, ולכן לתיבת הסימון אין כל השפעה על הדחייה, וזו הסיבה שהחלפתה מפיקה את אותה שגיאה עם חותמת זמן אחרת.
הטעות ההפוכה נפוצה באותה מידה. שיוך IKE מוצלח אינו מוכיח שהצעת ESP מקובלת, ובוודאי אינו מוכיח שקבוצת שלב 2 תואמת. התייחסו למנהרת ניהול שהוקמה כראיה לגבי שלב 1 בלבד. אנשים קוראים את השורה הירוקה כ«המנהרה פעילה», ואז מבזבזים שעה על השלב הלא נכון משום שדבר לא אמר להם שהמשא ומתן השני לא החל.
קראו את היומן לפני בחירת אלגוריתמים
אספו את ההודעות שמיד לפני הדחייה מה-backend שבאמת מטפל בחיבור, ותאמו אותן לאותו ניסיון. בלי התאמה כזו אתם קוראים את ההיסטוריה של חיבור אחר ומסיקים ממנה מסקנות.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanמתוך השורות האלה ענו על שתי שאלות: האם הוקם שיוך שלב 1, ואיזה חילוף נכשל. שתי התשובות האלה מצמצמות את החיפוש לרשימת מאפיינים אחת. הודעה עירומה בלי הקשר סביב אינה יכולה לעשות זאת, כמה מפתה הוא לנסות הצעה משרשור פורום. העתקת מחרוזת עובדת ממכונה עם backend אחר מחליפה בדרך כלל דחייה אחת באחרת, מעט מאוחר יותר.
התחביר של ה-backend אינו נוסע
רשמו את גרסת NetworkManager-l2tp ואת גרסת ה-backend של IPsec לפני שאתם משווים משהו. Libreswan ו-strongSwan אינם חולקים תחביר הצעות או קבוצות אלגוריתמים זהות, ולכן מחרוזת שעובדת באחד היא שגיאת תחביר בשני. ה-backend המותקן עשוי גם לסרב ל-IKEv1 לפי מדיניות, ואז שום הצעה לא תתקבל לעולם.
ה-README של הפרויקט מתעד את ההבדלים האלה בין ה-backends ומשאיר את שדות שלב 1 ושלב 2 נפרדים. קראו אותו כתיעוד של המבנה, לא כהזמנה להפעיל כל צופן היסטורי וקבוצה חלשה, משום שחיבור שמצליח רק כך אינו החיבור שהתבקשתם לבנות.
סכמו על החבילה, ואז אמתו את השלבים
שאלו את מפעיל השער אילו חבילות IKE ו-ESP נתמכות ומאושרות, ואז השוו את התשובה הזו להצעות בפועל של הלקוח ולא לקובץ התצורה שלו. אם המחלוקת היא ספציפית ב-PFS של שלב 2, קבעו קבוצה נתמכת או מדיניות ללא PFS שאושרה במפורש. אל תסיקו את המדיניות משם השגיאה.
כשהחפיפה היחידה דורשת קריפטוגרפיה שהארגון אינו מקבל עוד, ההחלטה שייכת לשער או למעבר פרוטוקול. הרחבת מחרוזת הלקוח עד שמשהו מנהל משא ומתן היא דרך לספק חולשה ידועה עם סימן ירוק לצידה.
לאחר שתתקנו את אי-ההתאמה האמיתית, אשרו את הקמת IPsec לפני שתחקרו L2TP ו-PPP, והתייחסו לכל דחיית אימות מאוחרת כשייכת לשלב הבא. אחר כך בדקו חידוש בתהליך הבדיקה המאושר, משום שהקמת השיוך הראשון אינה אומרת דבר על שאר חייו.