OpenVPN 3 Linux: קראו את שגיאת ה-D-Bus לפני שאתם מחזירים גרסה
חמישה שירותים, חזית אחת. שייכו שגיאת D-Bus לרכיב שסירב, בדקו אם קיימת הפעלה, ואז תקנו בגבול הזה.
כשלים ב-OpenVPN 3 Linux מגיעים כשגיאת מתודה של D-Bus עם שם לא מוכר, והפיתוי הוא להוריד את גרסת החבילה ולקוות. הלקוח אינו תוכנית אחת: חזית של שורת פקודה מדברת דרך האפיק עם שירותים שמחזיקים את הפרופילים, את ההפעלות, את מנוע ה-VPN ואת שינויי הרשת המיוחסים. ההחלטה איזה מחמשת אלה מחזיק בקריאה שנכשלה היא רוב האבחון, והיא עולה פקודה אחת במקום החזרת גרסה. מה שלפניכם הוא אותה החלטה, בסדר שבו הכשלים מופיעים בדרך כלל.
חמישה בעלים מאחורי פקודה אחת
חמישה תהליכים חשובים, ולכל אחד שם אפיק משלו: החזית שמקבלת את הפקודה שלכם, מנהל התצורה ששומר את הפרופילים ואת מדיניות הגישה שלהם, מנהל ההפעלות שמחזיק באורך החיים של ההפעלה, החלק האחורי שמריץ את החיבור דרך OpenVPN 3 Core Engine, ושירות תצורת הרשת שמתקין את הממשק, את המסלולים ואת הגדרות ה-DNS. שגיאה שמציינת אובייקט תצורה אינה אפוא שגיאה של החלק האחורי, וחלק אחורי שלא מתחיל אינו כשל אימות. סיווג ההודעה לאחת מאותן שורות חייב לקרות לפני שמשהו משתנה, מפני שכל צעד מאוחר יותר תלוי בשאלה איזו שורה נכונה. ניחוש השורה הוא הדרך שבה תיקון קצר הופך לאחר צהריים של עבודה עם חבילות.
שאלו את אפיק המערכת אילו שירותים נוכחים לפני שתשאלו כל דבר אחר, ואז ודאו שהחלקים המותקנים מסכימים על גרסה. OpenVPN 3 Linux רושם את השירותים האלה כיחידות מערכת, ולכן האפיק שיש לשאול הוא אפיק המערכת, שאילתת הגרסה דורשת סמכות ניהולית, ורשימה שנעשתה עם --user קוראת את הפעלת הכניסה שלכם, שבה היחידות לעולם אינן מופיעות. שירותים מופעלים לפי דרישה וחלקם מסתיימים כשהם אינם פעילים, ולכן שירות שחסר לפני הבקשה הראשונה שלכם פשוט עדיין לא נשאל על דבר. שלוש הפקודות שלמטה עונות על נוכחות, גרסה ומצב יחידה בלי לפתוח הפעלת VPN.
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'מה כל רשימה באמת מוכיחה
התצוגות של הלקוח עצמו הן ההוכחה הזולה ביותר שיש, וכל אחת מהן מוכיחה פחות ממה שנדמה. פרופיל ברשימת התצורה מראה שפרופיל יובא ושום דבר על השאלה אם מישהו רשאי להתחבר איתו. הפעלה ברשימת ההפעלות מראה שקיים אובייקט הפעלה ושום דבר על השאלה אם האימות המרוחק הסתיים.
openvpn3 configs-list
openvpn3 sessions-listנתיבי אובייקט בפלטים האלה מזהים אובייקטים מנוהלים באפיק ולא קבצים, ולכן אי אפשר לערוך אותם, ונתיב שנרשם קודם מתיישן ברגע שההפעלה הזו מתנתקת. שימוש חוזר באחד מהפתקים שלכם מייצר שגיאות "no such object" שאין להן שום קשר ל-VPN. טבלת השלבים שלמטה מפרידה בין מה שכל צעד בחיבור מבסס לבין מה שהוא משאיר פתוח, ובהבחנה הזו בדיוק תלויה החלטת החזרת גרסה. קראו את השורה שמתאימה להוכחה שלכם, ואז קראו שוב את טקסט השגיאה.
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
קריאת החיבור חוזרת לפני שהמנהרה קיימת
קריאת החיבור נותנת לכם הפעלה למעקב וחוזרת, ולכן קריאה שנראית מוצלחת ואחריה שתיקה היא מצב ביניים רגיל ולא סתירה. החזית עדיין חייבת לעקוב אחרי שינויי מצב ולהשיב לכל בקשת אינטראקציה. פרופיל שזקוק לאישור ואינו מקבל תשובה ממתין במצב שנראה בדיוק כמו חלק אחורי תקוע. מצב ההמתנה הזה ראוי לזיהוי, מפני שהוא שולח אנשים לרכיב הלא נכון.
בזמן שניסיון פועל, עקבו אחרי רשימת ההפעלות ואחרי היומן של החזית עצמה עבור אותו פרופיל. הפעלה שלעולם אינה יוצאת ממצב ההתחלה שלה מציינת את הרכיב שנעצר, והיומן מציין אותו בדרך כלל כבר בשורות הראשונות. החזיקו את שם הפרופיל בהישג יד, מפני שפקודת היומן מקבלת פרופיל ולא נתיב הפעלה, וזו סיבה נוספת לקרוא את הרשימה שוב במקום להשתמש שוב בנתיב.
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6קריאת היומן של רכיב אחד בלי לפתוח הפעלה
כשהחזית אינה מדווחת דבר שימושי, פנו אל הרכיב שתיעד את הכשל ביומן במקום להתחיל חיבור אחר. עם מתעד systemd-journald מוגדר, תצוגת היומן המצומצמת של המנהל קוראת את האירועים של רכיב אחד בלי לגעת במדיניות האפיק ובלי לפתוח הפעלה, וזה חשוב מפני שאבחון שמשנה את המערכת שהוא מודד מוכיח מעט מאוד. סננו לפי יחידה ולא לפי תגית syslog: יחידות השירות הבודדות אינן מבטיחות מזהה משותף, ולכן שאילתה לפי תגית עשויה להחזיר עמוד ריק בעוד היחידה עצמה תיעדה את הכשל.
רשמו ארבעה שדות לפני שתבקשו עזרה ממישהו: השם המלא של השגיאה, השירות והאובייקט המעורבים, חתימת הזמן וגרסאות החבילות המותקנות. אלה מה שמתחזק צריך, ואף אחד מהם אינו דורש להדביק פרופיל או אישור לכרטיס. הרחבת מדיניות הגישה לאפיק כדי להשתיק את השגיאה אינה אבחון, היא מוחקת את הגבול שקרא לרכיב בשמכם. התוכן הפרטי של הפרופילים נשאר מחוץ לדוחות משותפים מאותה סיבה כמו אישורים.
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>תיקון הגבול שסירב
לכל שורה במפה תיקון משל עצמה, והשורות אינן מחליפות זו את זו. פעולה שנדחתה על פרופיל היא שאלה של מדיניות ובעלות, בעוד חלק אחורי שאינו מופעל הוא שאלה של שירותים ואריזה. שרת שדוחה אימות אינו אף אחד מהשניים, ולכן החלפות סיסמה חוזרות אינן יכולות לתקן בעיית הפעלה מקומית. בחירת התיקון הלא נכון היא הדרך שבה בעיית מדיניות הופכת להתקנה מחדש.
אחרי שינוי חבילות, ודאו התקנה עקבית ונתמכת במקום להעתיק קובץ בינארי ישן למקומו. החזרת גרסה מבוקרת היא תשובה לגיטימית לרגרסיה מאושרת, בתנאי שהחבילות נשארות תואמות ושיש נתיב חזרה לתחזוקה נתמכת. הקימו את הנתיב הזה לפני שהשירות מפסיק לעלות, ולא אחרי.
פלטפורמה אחרת יכולה לחלוק את אותה ספריית VPN בסיסית בלי לחלוק את שירותי האפיק של לינוקס, ולכן כשל דומה למראה ב-Windows אינו אומר דבר על זה. סקירת D-Bus מתעדת את נתיבי האובייקטים שנחשפים עבור תצורות והפעלות, וזה החלק בארכיטקטורה שעליו נשען האבחון הזה. קראו אותה פעם אחת, והשגיאה הבאה תגיע עם רכיב שכבר מחובר אליה.