חריגות VPN לפי אפליקציה נשברות כששירות משותף מביא את הנתונים

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

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

מצאו את התהליך, לא את החלון

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

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

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

התייחסו ל-DNS כנתיב משל עצמו

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

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

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

אל תרחיבו עוזר משותף

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

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

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

בדקו את כל זרימת העבודה, לא את השלב שנכשל

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

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

השאירו סיבה, לא רשימת שמות

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

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