איפה יומני ה־VPN של Azure Point-to-Site? חפשו ב־Monitor

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

למה החיפוש המובן מאליו נכשל

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

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

חברו את הגדרת האבחון למשאב השער

פתחו את Monitor, אחר כך Diagnostic settings, והוסיפו הגדרה חדשה שהיעד שלה הוא שער הרשת הווירטואלית עצמו ולא הרשת הווירטואלית שמכילה אותו. בחרו את קטגוריית האבחון Point-to-Site, זו שנקראת P2SDiagnosticLog, כי היא נושאת את רשומות החיבור לכל לקוח; הוסיפו את קטגוריות המנהרה, הנתיב או IKE רק עבור שגיאות site-to-site שהן מכסות. לאחר מכן שלחו את הנתונים אל מרחב עבודה של Log Analytics שאתם שולטים בו, עם תקופת שמירה שבחרתם בכוונה. רוב החיפושים הכושלים הם הגדרה שמחוברת למשאב הלא נכון, לא תכונה חסרה.

רשימות הקטגוריות שונות לפי סוג השער והדור. אם קטגוריית Point-to-Site חסרה, ייתכן שהשער קדום לתכונה או מריץ SKU שלעולם אינו פולט אותה, ולכן בדקו את הקטגוריות הנתמכות לפני שתחפשו בעיית הרשאות. שער בלי קטגוריית Point-to-Site אינו שבור; הוא פשוט אינו יכול להיות המקור של אותה רשומה, והתחליף הקרוב ביותר הוא קטגוריית המנהרה או IKE, שמתעדת את כתובת הלקוח אף שאינה מתארת הפעלת Point-to-Site. אשרו את רשימת הקטגוריות לפני שתפתחו מקרה תמיכה על יומנים חסרים.

קראו את הרשומות בטבלה שהמצב שלכם משתמש בה

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

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

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

הצמידו את רשומת השער לתצוגה של הלקוח עצמו

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

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

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

שמירה, היקף ורשומת ה־runbook

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

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