האם שדרוג Ubuntu שבר את L2TP/IPsec? השוו את הצעות IKEv1

החיבור עבד ביום חמישי, השדרוג רץ ביום שישי, וביום שני הלקוח מסתובב על “connecting” ומוותר. אותו מחשב נייד, אותו שרת, אותו חשבון, אותו מפתח משותף מראש. שום דבר בפרופיל לא נערך, ולכן החשודים המובנים, הסיסמה וחומת האש, מבזבזים את הזמן שלכם.

מה שהשתנה הוא רשימת הטרנספורמציות שהמכונה שלכם מוכנה להציע. שתי ערימות ה-IPsec שבשימוש ב-Ubuntu, strongSwan ו-Libreswan, גוזרות אלגוריתמים שאינן רואות בהם עוד בטוחים, ולתוסף ה-NetworkManager שעומד לפניהן יש רשימה משלו, שנעה לפי לוח זמנים אחר. שרת מוצמד ל-3DES, SHA1 וקבוצת Diffie-Hellman של 1024 ביט עלול בסופו של דבר לא לשמוע דבר שהוא מקבל.

מה השדרוג באמת שינה

שתי שכבות מזינות את הצעת IKEv1. הדמון מספק סט הצעות ברירת מחדל מהודר, ותוסף ה-L2TP או נשען עליו או מספק רשימה משלו. לפני NetworkManager-l2tp 1.2.16 התוסף נשען עליו, ולכן ההצעה שלכם הייתה מה שהדמון המותקן חשב לסביר. מ-1.2.16 והלאה התוסף שולח רשימה מתועדת שנבנתה בדגם של לקוחות Windows ו-Apple, והרשימה הזו רחבה מברירת המחדל הישנה אך אינה מכילה עוד כל צירוף ישן בראש התור.

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

יש מלכודת קטנה יותר באותו אזור. שני הדמונים כותבים את קבוצות Diffie-Hellman של העקומה האליפטית אחרת, האחד כותב ecp384 והשני ecp_384. הדביקו את האיות השגוי בתיבת הדו-שיח Advanced והדמון ידחה את ההגדרה כבלתי ניתנת לניתוח, מה שמופיע ביומן כבעיית משא ומתן ולא כשגיאת הקלדה בתצורה.

קראו את הכשל לפני שאתם משנים משהו

התחילו באיזה backend אתם מריצים, מפני שהתשובה קובעת גם את התחביר וגם את מיקום היומן.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

אחר כך קראו את ההחלפה עצמה. ב-strongSwan הדמון כותב ליומן המערכת במהדורה נוכחית ול-/var/log/syslog במהדורה ישנה יותר, והחלק המעניין הוא ההצעה שהוא שולח, לא השורה האחרונה. אתם מחפשים ניסוח על כך שאין הצעה מתאימה, וזו בעיית אלגוריתם; כשל אימות, שמצביע על המפתח או על החשבון; או פסק זמן רגיל, שמצביע על נגישות.

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

שלב 1 ושלב 2 הם הימורים נפרדים

IKEv1 מנהל משא ומתן פעמיים. המצב הראשי בונה את אסוציאציית האבטחה של IKE מאלגוריתם הצפנה, אלגוריתם שלמות, קבוצת Diffie-Hellman ושיטת אימות. המצב המהיר בונה לאחר מכן את אסוציאציית ה-ESP שתישא את L2TP. השרת חופשי לקבל את הראשונה ולדחות את השנייה, ולכן פרופיל חצי-נכון נכשל מאוחר ממה שציפיתם ונראה כמו תקלה אחרת.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

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

שנו שדה אחד ואז חזרו על הבדיקה

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

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