למה לקוח ה-OpenVPN שלך נשאר למטה אחרי פסק זמן אחד

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

התחל ממה שהיחידה באמת עשתה, לא ממה שהניטור טוען. systemctl status openvpn-client@office ו-journalctl -u openvpn-client@office -n 50 מראים את סיבת היציאה ואת השורה האחרונה שהלקוח כתב לפני שעזב.

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

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

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

בחירה בין ping-exit ל-ping-restart

בחר ping-restart למחשב נייד או לאתר מרוחק שאמור להתרפא בעצמו, ושמור את ping-exit למקרים שבהם מנהרה מתה חייבת לעצור את התהליך כדי שמשהו אחר יוכל לפעול עליה. המספרים פחות חשובים מהיחס: ping 10 עם ping-restart 60 פירושו עשר שניות של שקט לפני בדיקה ושישים לפני האתחול, מה שאגרסיבי בקישור סלולרי עם אובדן וסביר בקישור קווי. כתוב את הסיבה לצד השורה, אחרת הקורא הבא יניח שערכי ברירת המחדל היו מכוונים.

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

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

במארח systemd השינוי הקבוע הקטן ביותר הוא קובץ drop-in אחד: Restart=on-failure ו-RestartSec=10 ב-/etc/systemd/system/[email protected]/restart.conf. קובץ drop-in נקרא רק כאשר systemd טוען מחדש את ההגדרות שלו, לכן הרץ systemctl daemon-reload לאחר מכן. אמת עם systemctl show -p Restart -p ExecMainStatus openvpn-client@office במקום להניח שהערך הגיע. המופע בשם הקובץ חייב להיות הפרופיל שהיחידה טוענת באמת, ולכן קובץ שנכתב עבור office לא עושה דבר עבור openvpn-client@home.

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

Restart=always פועל גם אחרי עצירה מכוונת. השתמש ב-systemctl stop לתחזוקה, והסתר את היחידה אם היא חייבת להישאר למטה בזמן שאתה עובד.

לתפוס את הדליפה בזמן שהמנהרה למטה

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

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

בדוק זאת בעצירה מכוונת של הלקוח. הרץ systemctl stop openvpn-client@office, ואז curl -m 5 https://example.com, שאמור להיכשל במקום להצליח דרך הקישור הפיזי. הצלחה פירושה שכלל חומת האש חסר או מתירני מדי.

התחבר מחדש, ודא שהמנהרה נושאת תעבורה שוב, ורק אז הוסף את הבדיקה לניטור. סקירת ip addr מ-cron עבור התקן tun היא הפיקוח שנכשל בתדירות הגבוהה ביותר, כי עם persist-tun ההתקן שורד את הסשן והבדיקה מדווחת על בריאות בזמן ששום דבר לא נישא.