האם מתג ההגנה שלכם יחסום את האפליקציה שהחרגתם מהמנהרה?

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

שתי מדיניויות, מכונה אחת

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

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

כתבו את רשימת האפליקציות לפני הכלל

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

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

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

מה הלקוח עושה בזמן תקלה

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

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

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

שלושה רגעים: מנהרה למעלה, מנהרה למטה, התחברות מחדש

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

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

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

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