OpenVPN מציג active (exited)? מצאו את המופע שהפעלתם
active (exited) אינו מנהר, אלא משימה חד-פעמית של /bin/true ש-RemainAfterExit מחזיק. מצאו את המופע, קראו את הקובץ שאליו הוא מפנה, ואז קראו את היומן שלו.
אתם בודקים את המנהר, מריצים systemctl status openvpn ומקבלים active (exited) בלי Main PID ועם רשימת תהליכים ריקה. הקריאה הטבעית היא שהשירות התחיל ומת, לכן אתם פותחים את היחידה, מוצאים /bin/true ומסיקים שהחבילה שבורה. באריזת Debian המצב הזה הוא העטיפה שפועלת כמתוכנן, והמנהר חי באחת מיחידות המופע שהיא מפעילה. היחידה המצטברת לעולם לא תגיד לכם איזה מופע בנה אותה.
מה active (exited) באמת אומר ביחידה הזו
היחידה הארוזה היא משימה חד-פעמית: ה-ExecStart שלה הוא /bin/true, ו-RemainAfterExit=yes הוא מה שמחזיק יחידה שהסתיימה מדווחת כ-active (exited). הסירו את ההנחיה הזו ואותה משימת /bin/true מוצלחת מסתיימת ב-inactive (dead), וזה בדיוק המצב שאנשים מצפים לו וקוראים אותו בטעות בכיוון ההפוך. הפקודה היא ממלאת מקום, והיחידה מדווחת על עבודה שיחידות אחרות עושות. שום דבר בסידור הזה אינו שבור, והחלפת /bin/true משנה את חוזה האריזה ולא את המנהר.
העטיפה מאצילה. היא מפעילה את יחידות המופע שתצורת החבילה או המחולל של systemd שלה מספקים, ולכן רשימת תהליכים ריקה אינה מוכיחה דבר על המנהר. כשלא נבחר שום מופע, העטיפה עדיין מצליחה ועדיין לא מפעילה דבר. המצב עונה אם העטיפה רצה, לא אם קיים מנהר.
קראו את שלוש השורות של פלט ה-status ולא את המילה בסוגריים. Loaded מציין את קובץ היחידה ש-systemd קרא, Active נושא את חתימת הזמן של ההרצה המוצלחת האחרונה, והיעדר Main PID מתאים למשימה חד-פעמית שהסתיימה. שלוש השורות האלה הן גם הדרך להבדיל את העטיפה הזו משירות שקרס שנייה אחרי ההתחלה.
רשמו את היחידות לפני שתקראו שוב את ה-status
שאלו את systemd מה קיים לפני שתשאלו מה רץ. תבנית יכולה להיות מותקנת בעוד שום מופע לא נוצר, ורק יחידה שנוצרה נושאת מנהר. התחילו בקבוצה הטעונה:
systemctl list-units 'openvpn*'
הרשימה הזו היא מה ש-systemd טען ברגע זה, וזה הדבר הקרוב ביותר למלאי מנהרות. קבצי יחידה מותקנים עונים על שאלה אחרת, והרשימה הזו עדיין מציגה תבנית כשלא נוצר דבר:
systemctl list-unit-files 'openvpn*'
קראו את שתי הרשימות יחד, כי תבנית בשנייה ומופע בראשונה הן תשובות שונות. תבנית שקיימת ומופע שרץ אינם אותה עובדה, ורק השנייה פירושה מנהר. פריסות חבילה נבדלות גם בין הפצות וגרסאות OpenVPN. תבנית openvpn@ ישנה יותר, זוג client ו-server נפרד ועטיפת הפצה יכולים כולם להיות לגיטימיים באריזה שלהם.
התאימו למכונה שלכם ולא למדריך שמצאתם. שם המופע בפלט של מישהו אחר יכול להיות office בעוד שלכם הוא home או work. מה שמועבר הוא השיטה, לא המחרוזת.
עקבו אחר שם המופע אל הקובץ שהוא קורא
בתבנית ה-client של ה-upstream ספריית העבודה של היחידה היא /etc/openvpn/client והפקודה שלה לוקחת משם %i.conf, לכן openvpn-client@office קורא את /etc/openvpn/client/office.conf. אשרו את המיפוי הזה על היחידה המותקנת במקום לסמוך על הדוגמה, כי התבנית שיש לכם יכולה להיות ישנה יותר או שכתוב של ההפצה:
systemctl cat [email protected]
קראו את ה-drop-in שמופיעים בתחתית הפלט הזה, כי קובץ תחת .d/ יכול לשנות את ExecStart, את ספריית העבודה או את נתיב התצורה. פרופיל שהורדתם בשם office.ovpn אינו הקובץ שהמופע פותח. הפער הזה הוא הסיבה הרגילה לכך ששגיאה מציינת נתיב שמעולם לא ערכתם.
נתיבים יחסיים בתוך הפרופיל הם המלכודת הבאה. העברת הקובץ הראשי כשההפניות ca, cert ו-key נשארות יחסיות מחליפה שגיאת קובץ חסר בשגיאת קובץ חסר אחרת. השנייה מצביעה על קובץ שהייתם בטוחים שקיים, ולכן ספריית הפרופיל חשובה יותר משם הקובץ.
הפעילו אותה, ואז קראו את היומן של אותו מופע
הפעילו את המופע שבדקתם זה עתה, כי היומן של היחידה המצטברת לא יכיל את שגיאות המנהר. לאחר מכן קראו את היומן של האתחול הזה וחפשו בסדר הזה שגיאת תצורה, שגיאת גישה לקובץ ושגיאת חיבור, כי כל אחת נכשלת בשלב אחר של ההתחלה.
sudo systemctl start [email protected]
journalctl -u [email protected] -b
התחלה והפעלה אוטומטית הן החלטות נפרדות: start מריץ את היחידה עכשיו, enable מסדר את האתחול הבא, ו-enable --now עושה את שתיהן בצעד אחד. daemon-reload קורא מחדש הגדרות יחידה ואינו מפעיל מחדש תהליך שרץ ואינו מחיל פרופיל שנערך. לאחר ששיניתם את הפרופיל, הפעילו מחדש את המופע, כי זה מה שקורא את הקובץ מחדש.
אל תשימו מנהל שני על אותו מנהר
NetworkManager ומנהלי הסשן של OpenVPN 3 מחזיקים במצב החיבור שלהם, ומופע systemd לצד אחד מהם שם שני בעלים על אותו מנהר. הסימפטום הוא מנהר שעולה ומוחלף שניות לאחר מכן, או כזה שמסרב להישאר עצור. בחרו במנהל שההפצה שלכם מתעדת לשולחן העבודה, והשתמשו ב-systemd בכוונה בשרת.
בדקו אם קיים כבר בעלים לפני הפעלת מופע. כשאפלט שולחני מציג את החיבור, המופע שאתם מפעילים מתחרה בו במקום להשלים אותו. השביתו את המנהל שאינכם משתמשים בו במקום להריץ את שניהם ולקוות שהסדר יחזיק. הקונפליקט הזה גם מסביר יומנים שבהם מנהר מוקם ואז מפורק על ידי תהליך שמעולם לא הפעלתם.
ענו על השאלה המקורית בשם המופע, בקובץ שהוא קרא ובשורת היומן שנכשלה. ההערות של OpenVPN על אינטגרציה עם systemd מתארות את פריסת התבנית ואת מיפוי הקובץ שדרכו נפתר שם המופע.