PSK של L2TP/IPsec נדחה: עברו קודם בדיאלוג, ואז בקבצים

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

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

התחילו בדיאלוג, אבל אל תסמכו על השדה

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

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

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

עקבו אחרי המפתח אל תוך /etc/ipsec.d

התוסף אף פעם לא מוסר את ה-PSK לדמון ה-IPsec כארגומנט בשורת פקודה. במקום זאת הוא שומר את הערך בקובץ סודות ודואג שהדמון יטען את הקובץ הזה, על ידי הוספת שורת include ל-/etc/ipsec.secrets אם אין כזו. מה שהדיאלוג מחזיק הוא קלט לקובץ הנוצר הזה, לא הערך שבשימוש.

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

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

גרסאות ישנות יותר של התוסף כתבו קובץ אחד לכל חיבור, שנקרא על שם ה-UUID של החיבור, למשל /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. מחיקת פרופיל ביישומון אינה מוחקת את הקובץ הזה באופן אמין. אם קובץ ישן משרת קודם עדיין נמצא בדיסק ועדיין נכלל, הדמון עלול לבחור סוד ששייך לפרופיל שאינכם משתמשים בו עוד, והחיבור נכשל בעוד השדה הגלוי נכון.

הבינו מה עשתה השינוי ב-1.2.12 לשדרוגים

גרסה 1.2.12 של התוסף החליפה את קובצי הסודות לכל חיבור בקובץ משותף אחד, /etc/ipsec.d/ipsec.nm-l2tp.secrets. שדרוג אינו מנקה את הקבצים הישנים לפי UUID, ושורת include /etc/ipsec.d/*.secrets קיימת עדיין טוענת אותם. גרסה 1.2.16 שינתה את הטיפול בהצעות ברירת המחדל, לא את פריסת הסודות.

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

הפרידו את התווים שתבנית האחסון אינה יכולה להחזיק

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

מאז 1.2.12 הערך הנשמר אינו טקסט פשוט. התוסף מקודד את ה-PSK ב-base64 לפני שהוא מגיע לקובץ, והערות השחרור מציגות את הקידוד הזה כסיבה לכך שמרכאה כפולה מקובלת עכשיו במפתח. מרכאה שהוקלדה בשדה ניתנת אפוא לייצוג; אותו דבר אינו נכון לכל תו בקרה.

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

קראו איזו שכבת אימות נכשלה

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

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

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