ניטור VPN של Azure Site: להתאים את מצב המנהרה לבדיקה אמיתית

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

מתחילים מהתסמין הכושל, לא מהמנהרה

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

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

מקמו את הבדיקה היכן שנמצאים המשתמשים

עבור אפליקציה מסניף ל-Azure, הריצו את הבדיקה הסינתטית ממארח ברשת עומס העבודה של הסניף וכוונו אותה לנקודת הכניסה הפרטית של HTTPS שאליה המשתמשים מגיעים באמת. בדיקה שמופעלת מהשער משתמשת בכתובת מקור אחרת ולעתים קרובות בנתיב מדיניות אחר, ולכן היא עשויה לעבור בשעה שכל משתמש נכשל. Azure Connection Monitor תומך בבדיקות TCP, ICMP ו-HTTP עם קבוצות בדיקה וספים, ולמקורות המקומיים שלו יש דרישות סוכן שונות מאלה שבצד Azure. בדקו את הסידור הנתמך כיום במקום להעתיק מתכון ניטור קלאסי שהוצא משימוש מבלוג.

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

בחרו בדיקה שמתאימה לשירות

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

ICMP היא האפשרות החלשה משלוש, מכיוון שהרבה ערימות מפילות אותו לפי מדיניות ופינג כושל מוכיח מעט מאוד.

הביאו את שני האותות אל Elastic בלי להמציא אותם

שער ה-VPN מפיק מדדי פלטפורמה כגון בייטים יוצאים ונכנסים של המנהרה ומוני איבוד מנות, ויכול לשלוח יומני אבחון בקטגוריות הכוללות אירועי מנהרה ו-IKE. תוצאות Connection Monitor מגיעות דרך Azure Monitor כמדדים ודרך מרחב עבודה של Log Analytics כרשומות יומן. שום דבר מזה אינו מופיע מעצמו באינדקס של Elastic. בחרו צינור נתמך אחד למדדים ואחד ליומנים, בדרך כלל קלט Azure Event Hub או אינטגרציית Azure Monitor, ואמתו מה האינטגרציה המותקנת באמת קולטת לפני שתסמכו על תבנית האינדקס.

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

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

התריעו על ההבדל, לא על הצבע

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

לוח מחוונים מלא בדגימות מוצלחות של אתמול לא צריך להיקרא כנתיב בריא היום.

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