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

המיתוס: החרגת האפליקציה מחריגה את התעבורה שלה

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

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

מצא את בעל ההעברה

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

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

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

האימות שורד שינוי נתיב

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

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

בדוק את העדכון ואז תעד את הבעלים

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

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

מאמרים קשורים