Systemd מול NetworkManager: מי מפעיל את ה‑VPN באתחול?
שלושה מנגנונים יכולים להעלות את אותו פרופיל Ubuntu, כל אחד עם טריגר אחר. השוו ביניהם, השאירו בעלים אחד והסירו את הכפילות.
שני מחשבי Ubuntu מאותה תמונה, פרופיל VPN אחד, תוצאות הפוכות בכניסה: באחד המנהרה כבר למעלה לפני שהשולחן מופיע, ובשני היא לא עולה לעולם. הפרופיל אינו המשתנה כאן. מה ששונה הוא איזה משלושה רכיבים קיבל הוראה להפעיל אותו, ושלושת אלה אינם חולקים מתג אחד.
השוואה ביניהם זה לצד זה מהירה יותר מניחוש. כל אחד מהם נכשל באופן מזוהה, וזה מה שהופך את ההשוואה לכדאית.
שלושה מפעילים עם שלושה טריגרים שונים
שירות openvpn הארוז הוא המסלול הוותיק ביותר. סקריפט ה-init שלו קורא רשימת הפעלה אוטומטית מתוך /etc/default/openvpn. אם הרשימה מוערת או נותרת ריקה, הסקריפט מפעיל כל תצורה שהוא מוצא באותה תיקייה במקום את זו היחידה שהוספת. קובץ אחד שהוסף למנהרה אחת יכול להעלות כמה בשקט.
| Starter | What triggers it | Typical failure |
|---|---|---|
| Init script and templated units | Boot, plus anything in the autostart list | Starts every config, not the one you meant |
| NetworkManager secondary | Activation of the base Wi-Fi or Ethernet profile | Nothing happens until that base link comes up |
| Hand-written unit or wrapper | Whatever its WantedBy and ExecStart say | Runs a different binary or environment than your shell |
השורה השנייה היא זו שאנשים מגדירים לא נכון. NetworkManager מחזיק בפרופיל המיובא ויפעיל אותו, אבל רק כמשני של חיבור אחר, כלומר הטריגר שייך לקישור הרשת ולא ל‑VPN.
השוו את עלות ההגדרה ואת ההיקף
המסלול של סקריפט ה-init עולה שורה אחת ומכסה כל תצורה במחשב. זה מתאים לנתב ולא מתאים למחשב נייד שמתחבר לרשתות שונות. המסלול של NetworkManager עולה חיפוש UUID וקושר את המנהרה לחיבור בסיס אחד. הוא עולה ברשת של העבודה ונשאר למטה ברשת של מלון.
יחידה שנכתבה ביד עולה הכי הרבה ומקנה את השליטה הרבה ביותר, כולל סדר מול שירותים אחרים. ההיקף הוא הגורם המכריע. אם במחשב רשת אחת ומנהרה אחת, השירות הארוז הוא ישר וצפוי. אם המנהרה אמורה לעקוב אחרי רשת Wi-Fi מסוימת, המשני הוא היחיד מבין השלושה שמבטא את התנאי הזה בלי סקריפטים נוספים.
בחרו בעלים אחד והסירו את האחרים
פרופיל שמופעל על ידי שני בעלים מייצר תזמון שמשתנה בין אתחולים, וזה גרוע מכל אחד מהמנגנונים לבדו. בחרו את הבעלים, ואז השביתו את המסלול המתחרה בכוונה ולא במקרה.
# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'
# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"אם המסלול הארוז הוא זה שמוצא משירות, עשו זאת בסדר הנכון: הגדירו את AUTOSTART ל‑none, הריצו systemctl daemon-reload כדי שהיחידות שנוצרו יקלטו את הרשימה החדשה, ואז השביתו את מופע התבנית שאינכם רוצים עוד. דילוג על הטעינה מחדש משאיר את היחידות הישנות פעילות, וזה נראה כאילו לשינוי לא הייתה שום השפעה.
עצירה שנתקעת היא בעיה נפרדת עם תשובה מוגבלת. TimeoutStopSec מגביל כמה systemd ממתין לפני שליחת SIGKILL. קובץ drop-in הוא המקום הנכון לקבוע אותו, כי עריכת היחידה הארוזה מאבדת את השינוי בשדרוג הבא.
ודאו מה באמת הופעל
אתחלו וקראו את הראיות במקום לסמוך על קובץ התצורה. היחידה שבעלת המנהרה תציג מצב פעיל וחתימת זמן התחלה שמתאימה לאתחול, וממשק ה‑VPN יהיה קיים לפני שתיכנסו.
systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0בדיקה אחת נוספת שייכת לכאן: ודאו שה‑ExecStart של היחידה מצביע על הקובץ הבינארי שאתם חושבים. לקוח שנבנה מקומית או חבילת snap זקוקים לעתים קרובות לנתיב מפורש או לעטיפת snap run, כי systemd אינו יורש את סדר החיפוש של ה-shell שלכם. השוואה בין command -v openvpn לקובץ היחידה מכריעה זאת בשניות.
כתבו את הבעלים הנבחר בהערות של המחשב, ליד שם הפרופיל. האדם הבא שיתקן מנהרה חסרה יתחיל מהשורה הזו במקום לחזור על ההשוואה.