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

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

תנו שם לנושא לפני הפקודה

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

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

פרופיל אחד: לשאול את הדבר שבבעלותו

עבור שירות Mac מקורי, בקרות חיבור הרשת ב-scutil מדווחות בדיוק על זה. הן קוראות את המצב של תצורה בעלת שם במקום להסיק משהו מממשק.

scutil --nc list
scutil --nc status "Office VPN"

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

בתוך אפליקציית Network Extension, קראו את המצב מאובייקטי המנהל והחיבור ולא מהמערכת. שימו לב להיקף כאן: טעינת תצורות שמורות מחזירה רק את אלו שהאפליקציה הקוראת יצרה, כך שתוצאה ריקה פירושה «אף אחת משלי», ולא «אין VPN ב-Mac הזה». הבדילו בין שאילתה שנכשלה לבין מצב מנותק מאומת, והתייחסו למצבי המעבר כתוצאות בזכות עצמן במקום לנסות שוב חיבור שכבר עולה.

משימה אחת: מוכנות היא פרדיקט נפרד

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

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

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

זרימה אחת: לבדוק את המסלול שנבחר

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

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

החזירו תוצאה שהקורא יוכל להשתמש בה

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

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

תיעוד ה-Network Extension בנושא טעינת תצורות מנהרה שמורות הוא המקום לאמת את ההיקף של האפליקציה הקוראת לפני שבונים עליו משהו.

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