L2TP: אות קטלני 15, NO_PROPOSAL_CHOSEN ו-modp1024 חסר

החיבור שלך נתקע, הלקוח יוצא, והשורה האחרונה על המסך היא death_handler: Fatal signal 15 received. השורה הזו מדווחת על קטיעה, לא על סיבה. שורה אחת למעלה ביומן IPsec יש כמעט תמיד NO_PROPOSAL_CHOSEN, והצמד מצביע על שלב 2 של ההחלפה, שבו הצדדים משווים אפשרויות הצפנה ו-hash ומפסיקים כשאין להם שום דבר משותף. פרטי ההתחברות עוד לא נשלחו בשלב הזה, ולכן הקלדה מחדש של הסיסמה לא יכולה לשנות את התוצאה.

בדרך כלל שני דברים מרוקנים את החיתוך הזה בלקוח לינוקס. ייתכן שהדמון המקומי כבר לא מיישם את קבוצת Diffie-Hellman שהפרופיל מבקש, או שהפרופיל נושא הצעה משלב 1 בשדה של שלב 2. שניהם משאירים עקבות ביומן, ואף אחד מהם אינו בעיית חשבון.

מה שתי ההודעות באמת אומרות

IKE מנהל משא ומתן בסבבים. שלב 1 בונה ערוץ מוגן ובוחר אלגוריתמים משל עצמו; שלב 2, ה-SA הבן, נושא תעבורה תחת סט נפרד. NO_PROPOSAL_CHOSEN הוא ההודעה שהמשיב מחזיר כאשר אף אחד מהשילובים המוצעים אינו מקובל, והוא מופיע כ-[ HASH N(NO_PROP) ] בתוך החלפת INFORMATIONAL.

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

קרא את המשא ומתן לפני שנוגעים בפרטי ההתחברות

העלה את רמת היומן במקום שבו הדמון כותב, ואז התחבר מחדש תוך צפייה בפלט. במארח NetworkManager התוסף L2TP מעביר את הרמה הזו ל-backend, וההודעות מגיעות ל-journal או לקובץ syslog הקלאסי בהתאם להפצה. כל אחד מאלה יציג את ההחלפה: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' או tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

שורה שמזכירה pluto מגיעה מ-libreswan, charon מ-strongSwan, ושתיהן מתארות את אותו מצב במילים שונות. הצורה ששווה לחפש היא זו שמציינת את הקבוצה החסרה, למשל algorithm 'modp1024' is not supported, כי היא הופכת כשל מעורפל לכשל מוגדר.

לאן נעלם modp1024

קבוצה 2 של Diffie-Hellman חלשה מספיק כדי שכמה הפצות הפסיקו לקמפל אותה לתוך libreswan החל מ-3.30. אז פרופיל שנכתב לפני שנים, או הועתק ממדריך שער שמפרט רק aes128-sha1-modp1024, מבקש מהדמון המקומי משהו שהוא כלל לא יכול לבצע. גרסאות חדשות יותר של NetworkManager-l2tp הופכות את התוצאה הזו לסבירה יותר: מ-1.2.16 הן מחליפות את הסט בהצעות בסגנון Windows 10 ו-iOS וזורקות את modp1024 ברגע שמזוהה libreswan. הצד השני לעיתים קרובות חף מפשע ועדיין מציע בדיוק את הקבוצה שהגדרת.

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

שני תיקונים ברדיוס פגיעה שונה

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

התיקון השני משאיר שער ישן נגיש על ידי התקנת strongSwan, שהחבילות שלו עדיין מיישמות קבוצה 2 ברוב ההפצות. זהו החלפת דמון, ולכן יש לזה מחיר: ודא אם מנהרות אחרות במארח תלויות בהגדרות libreswan לפני הסרתו, וצפה לדחיות SELinux בין NetworkManager לתוסף strongSwan בפדורה. הדחיות האלה מופיעות ביומן הביקורת ולא בעקבות IKE, ולכן מנהרה יכולה להיראות שבורה מיד אחרי התקנה מוצלחת. הסדר שעובד הוא קודם dnf install strongswan, אחר כך rpm -e libreswan.

מחרוזות הצעה שמתאימות, והמלכודות סביבן

כשצריך למלא את השדות ביד, שלב 1 ושלב 2 מקבלים ערכים שונים. זוג שידוע כעובד מול צד בסגנון Meraki מציע aes128-sha1-modp1024 בשלב 1 עם 3des-sha1-modp1024 מאחוריו, שניהם סגורים בסימן קריאה שהופך את הסט לקפדני, כך שרק ההצעות האלה נשלחות.

לאחר מכן שלב 2 מצטמצם ל-aes128-sha1 ו-3des-sha1 עם אותו סמן קפדני ובלי שום סיומת Diffie-Hellman. שורה בשלב 2 שנושאת -modp1024 היא ערך משלב 1 בשדה הלא נכון, והמשיב דוחה אותה בכל ניסיון חוזר. העתק את השורה הזו לפרופיל שני והפרופיל השני נכשל באותו אופן, וכך שגיאת הקלדה אחת הופכת לתקרית בכל הצי.

תקלות אחרות לובשות את אותה חלון קופץ בלי להיות אי-התאמות הצעה. ב-KDE ייתכן שסוג L2TP יופיע ברשימה כשהתוסף מותקן בעוד כל חיבור מת מיד, כי עורך החיבורים ועוזרי זמן הריצה מסופקים כחבילות נפרדות. מארחים בלי מסך יכולים לעשות שימוש חוזר בפרופיל משולחן עבודה עובד: העתק אותו מ-/etc/NetworkManager/system-connections/, הגדר את המצב ל-600, ואז הרץ nmcli con reload. העלה אותו עם nmcli con up id work-l2tp, מכיוון שהצורה החשופה דורשת UUID, והסר כל רשומת ifname מיושנת, אחרת המנהל עונה Could not find source connection כשכל השאר נכון.

מפתח משותף מראש יכול להישמר כטקסט גלוי או כ-0s ואחריו base64; שתי הצורות עובדות, אבל הערך חייב להתאים לשער בייט אחר בייט, כולל רווחים בסוף שהעתקת יחד איתו.