יומן ניפוי השגיאות של L2TP ריק? השגיאה כנראה נמצאת ב־journal

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

ארבעה תהליכים, שני יעדי יומן

החיבור מתחיל ב־IPsec, שהוא libreswan או strongSwan בהתאם להתקנה. אחר כך דמון L2TP, באופן מסורתי xl2tpd ובכמה בניות kl2tpd, מפעיל את המנהרה. לבסוף pppd מטפל באימות ובכתובות בתוכה.

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

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

אספו ניסיון אחד, ואז קראו את הסדר

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

הפקודות האלה בוחרות את התהליכים המשתתפים באתחול הנוכחי, וכדאי לאמת את נתיב התוסף בהפצה שלכם:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

שדות חוזרים בקריאה אחת בוחרים את האיחוד של התהליכים האלה, מה ששומר על הרצף בסדר זמן. במערכת מבוססת Debian השאילתה המקבילה היא dpkg -L; הנקודה היא למצוא היכן העוזר באמת נמצא לפני שמנסים להריץ אותו ביד.

שלושה תנאים קובעים את הצעד הבא

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

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

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

כדאי גם לאמת איזה backend של IPsec מותקן לפני שנוגעים בהגדרת ניפוי שגיאות. אפשרות תיעוד שנכתבה עבור strongSwan לא עושה דבר כשה־libreswan פועל, והחיבור ימשיך להיכשל באותו מקום בזמן שאתם עורכים קובץ שאף אחד לא קורא.

מצב ניפוי השגיאות משאיר קבצים

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

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

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

אחר כך שחזרו את העוזר הרגיל

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

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

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

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