מדוע OpenVPN מת לאחר שהמחשב הנייד מתעורר?

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

שחזרו את ההתעוררות לפני שאתם מאוטמים אותה

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

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

איפה וו שינה של systemd באמת נמצא

מדריכים ישנים רבים מצביעים על /etc/pm/sleep.d, תיקייה בבעלות pm-utils שאליה שינה מבוססת systemd לא פונה לעולם. systemd קורא ווים מ-/usr/lib/systemd/system-sleep/ ומ-/etc/systemd/system-sleep/, ומעביר תחילה את השלב ואחר כך את הפעולה, כך ש-pre ו-post הם הערכים היחידים שוו מסתעף עליהם. שמרו את העותק המקומי תחת /etc במקום לערוך קובץ ארוז, וזכרו שהסקריפט רץ כ-root באמצע המעבר, ולכן עליו לחזור מהר.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

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

שחזרו את השירות, הניחו ל-tun0

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

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

התמודדו עם התזמון שאינכם שולטים בו

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

פתרון שמות הוא מרוץ נפרד, כי ערימת הרשת של שולחן העבודה עשויה לשחזר DNS אחרי שהמנהרה כבר למעלה. בדקו חיפושים בנפרד עם resolvectl query internal.example במקום להסיק אותם ממסלול עובד. מנהרה שמנתבת נכון ולא פותרת כלום היא בעיית DNS, לא בעיית וו.

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