OpenVPN לא עולה בלי שגיאה? חפשו ביומן

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

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

שקט אומר שלא הסתכלתם בערוץ הנכון

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

הוסיפו systemctl show -p Result -p ExecMainStatus openvpn-client@office כדי להפריד יציאה נקייה מאות. מצב 1 עם Result=exit-code הוא החלטה של התוכנית; Result=signal או פסק זמן מצביעים דווקא על הסביבה, ושום כמות של עריכת פרופיל לא תשנה זאת. רשמו את שני הערכים לפני שאתם מפעילים מחדש משהו, כי הפעלה מחדש מוחקת את המצב החולף שיצר אותם.

שם המופע הוא חלק מהנתיב

יחידת התבנית הארוזה לא מקבלת נתיב קובץ. היא מקבלת שם מופע, והשם הזה מתווסף לספרייה כדי למצוא את הפרופיל: office מפוענח אל /etc/openvpn/client/office.conf באריזת Debian ו-Ubuntu. קובץ בשם office-v2.conf שהופעל בתור @office לעולם לא נקרא, והיחידה יוצאת בשקט כי מנקודת המבט שלה לא היה מה לעשות. ספריית החיפוש שונה בין מצב לקוח למצב שרת, ולכן אותה טעות מצביעה למקום אחר לגמרי כשמחליפים תבנית.

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

כשהתוסף מחזיק במנהרה, המסוף לא רואה דבר

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

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

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

שני קבצים בינריים, PATH אחד

בנייה ידנית המותקנת תחת /usr/local מנצחת בהפעלה ממעטפת, כי /usr/local/sbin בא לפני /usr/sbin ב-PATH ברירת המחדל של Ubuntu. יחידה לא משתמשת ב-PATH שלכם; היא מריצה את הנתיב המוחלט שכתוב בתוך ExecStart. לכן הגרסה שעובדת במסוף שלכם והגרסה שנכשלת כשירות יכולות להיות תוכניות שונות באמת.

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

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

הבדל סביבה נוסף מסתתר באותו מקום. יחידה ארוזה נשענת על ספריית ריצה תחת /run ש-systemd יוצר עבורה; יחידת החלפה בכתיבה ידנית שמשמיטה את ההגדרה הזו עלולה להיכשל לפני שתפתח קובץ אחד, והכשל נראה כמו סירוב כללי בלי שום הודעה של OpenVPN.

כשלים שהלקוח לא יכול לדווח עליהם

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

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

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