כיבוי שירותי VPN ופרוקסי ב-Linux בסדר הנכון

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

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

רשמו את היחידות לפני שעצרתם משהו

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

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

סיימו את העבודה, ואז עצרו את הצרכן

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

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

ExecStop ו-ExecStopPost הם כלים שונים

ExecStop= הוא פעולת העצירה הסינכרונית; ExecStopPost= הוא ניקוי שרץ גם אחרי הפעלה שנכשלה. פקודת עצירה שרק שולחת אות לתהליך וחוזרת משאירה את systemd ממשיך בזמן שהצרכן עדיין מתרוקן. כל מה שחייב לקרות בכל מקרה שייך לגרסה שאחרי, וכל מה שחייב לחסום את העצירה שייך לסינכרונית. בדקו את היחידה האפקטיבית ואת תוספותיה במקום לערוך קובץ של חבילה במקום.

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

הגבילו את העצירה ודעו מה הגבול עולה

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

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

התנתקו דרך הבעלים, ואז בדקו שלושה מקרים

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

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