Fail-open מול fail-closed: מה מחליט מפסק החירום של VPN
שני המונחים מתארים מה קורה כשהמנהרה נעלמת, לא כמה חזקה ההצפנה. ההיקף שתבחרו הוא שקובע אם התעבורה באמת דולפת.
המיתוס הוא ש-fail-closed הוא ההגדרה הבטוחה ו-fail-open היא הרשלנית. שניהם מתארים מה קורה לתעבורה לאחר שהמנהרה נעלמת, ואף אחד מהם לא משנה עד כמה טוב המנהרה הזו מצפינה. מדיניות fail-closed עם רשימת חריגים רחבה עלולה לדלוף יותר ממדיניות fail-open במכשיר שלעולם אינו יוצא מרשת המשרד. בחרו את התוצאה שתוכלו להסביר למי שבבעלותו התעבורה.
התווית מתארת תוצאה, לא חוזק
אוצר המילים מגיע ממערכות בקרה: fail-open מתיר פעולה כשמרכיב נכשל, fail-closed שולל אותה. בהחלה על VPN, המרכיב שנכשל הוא המנהרה, והשאלה היא אם התעבורה מורשית להמשיך בנתיב אחר. בחירת הצופן, אורך המפתח והפרוטוקול הם החלטות נפרדות.
הבלבול נמשך מפני שמפסק חירום נשמע כמו תכונת אבטחה, והספקים משווקים אותו ככזו. מבחינה מכנית זהו כלל ניתוב וחומת אש שחוסם תעבורה שהמנהרה הייתה אמורה לשאת, המיושם בלקוח, במערכת ההפעלה או בשער. כל שכבה שאוכפת אותו גם מגדירה את הכיסוי שלו, וכלל בשכבה אחת אינו מכסה שכבה אחרת. כלל בשער אינו יכול להגן על מחשב נייד שכבר עבר לרשת אחרת.
איך נראית כל תוצאה
אותה מדיניות יכולה להתנהג אחרת לגמרי בהתאם לכשל שתפגשו, לכן השוו את האירועים ולא את התוויות.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
השורה האחרונה היא זו שתופסת את מי שמניחים שמפסק חירום הוא מתג יחיד. כלל שנכתב עבור טבלת הניתוב של IPv4 מותיר את נתיב ברירת המחדל של IPv6 ללא שינוי, והיישום יכול להשתמש בו בשמחה.
ההיקף קובע אם יש דליפה
שאלו מה המדיניות מכסה לפני שתשאלו איזה מצב זה. כלל לפי יישום מגן על יישום אחד ושום דבר אחר, כלל ברמת המכשיר מגן על הכול למעט החריגים, וכלל בשער מגן רק על תעבורה שמגיעה לשער הזה. DNS זקוק להחלטה משלו, מפני ששאילתה שנשלחת לפותר מקומי יכולה לחשוף שמות גם כשהמטען חסום.
חריגים לרשת המקומית קיימים עבור מדפסות, שידור ופורטלי כניסה, וכל אחד מהם הוא חור בחסימה. תעדו אותם לצד המדיניות, אחרת מי שיירש את התצורה יקרא fail-closed כמוחלט.
התחברות מחדש וחסימה הן גם בקרות נפרדות. לקוח יכול להתחבר מחדש אוטומטית בלי לחסום אף פעם, או לחסום בלי להתחבר מחדש, והשילוב קובע מה משתמש חווה בזמן הפסקה.
הוכיחו זאת במהלך מעבר
בדיקת המצב היציב לא מוכיחה דבר. הפילו את המנהרה בכוונה ונסו את היישום שאמור להיות מוגן, ואז בדקו אם הוא הגיע לרשת. השוו את המחוון של הלקוח לתוצאה, מפני שמחוון שעדיין אומר מחובר הוא בדיוק המקרה שלשמו קיימת המדיניות. אם היישום המוגן מצליח, שם המצב לא משנה; יש לכם דליפה.
חזרו על כך מאתחול קר לפני הכניסה, במעבר מ-Wi-Fi לרשת סלולרית ועם היישום המוגן ברקע. אם תהליך הלקוח הוא שאוכף את החסימה, בדקו גם מה קורה כשהתהליך הזה נהרג ולא נסגר כראוי.
לבסוף, בדקו את מסלול הניקוי. אם לקוח מוסר בעוד הכללים שלו פעילים, השתמשו בהליך ההסרה המתועד של הספק במקום לכבות את חומת האש של מערכת ההפעלה, שמסירה הגנה לא קשורה בלי לענות למי שייך הכלל שנותר.