כבי את ה-Mac אחרי עבודת ה-VPN, לא לפניה

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

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

שני סדרי כיבוי, שתי תוצאות

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

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

למה השיתוף חייב ללכת לפני המנהרה

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

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

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

עצור את הלקוח שבבעלותו הסשן

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

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

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

הנח לכיבוי של מערכת ההפעלה

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

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

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

הכנס את המועד לתוכנית

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

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

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