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

שלוש שאלות קובעות את הטריגר

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

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

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

התאימו את האירוע לטענה שאתם מציגים

RecordWhat it provesWhat it leaves open
Rejected credentialsThe attempt failed at the credential stepWhether it was a stale client or a real person
Access-AcceptCredentials passed for this attemptAnything about tunnel state or policy
Policy match recordA rule matched the requestWhether later steps completed
Tunnel establishedThe gateway accepted a sessionWhether traffic flowed or the user got an address
Accounting StartUser service began at the accounting layerWhether the application behind it worked
Accounting StopThat session was closed, with a reason fieldWhether the reason is meaningful on your release

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

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

הפעלה אחת, התראה אחת

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

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

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

הפרידו בין ביקורת להתראה

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

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

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

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