האפליקציה לא צריכה לרוץ כשה־VPN דלוק: מה אוכף את זה

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

המיתוס: kill switch מונע מתוכניות להתחיל

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

הסידור שבאמת מחליט אם תוכנית רשאית להתחיל הוא בקרת יישומים. ב־Windows זה אומר AppLocker או WDAC, וב־macOS מנוהל זה אומר רשימת היתר שנאכפת על ידי פרופיל המכשיר. שניהם בלתי תלויים במנהרה, ולכן שתי הדרישות מתמזגות לאותו כרטיס ואז אף אחת לא מסופקת.

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

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

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

מה באמת עושה קונפליקט דו־כיווני

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

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

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

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

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

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

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