Azure VPN Client 3.4 מתנתק כל שעה: תדירות התחברות

משתמש אחד מתחבר, עובד, ואז מנתק פעם בשעה עם הודעה שהאימות מול Microsoft Entra פג. החיבור מחדש עובד והמחזור חוזר על עצמו כמו לפי שעון עצר. בשער point-to-site שבו לא נפרס דבר, התדגם הזה מצביע על הפריט ולא על המנהרה. ה-Azure VPN Client 3.4.0 החל לאכוף את תדירות ההתחברות של גישה מותנית במהלך הפעלה קיימת, מדיניות שלקוחות קודמים העריכו רק בעת ההתחברות.

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

שלב 1: קרא את ההודעה המדויקת

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

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

שלב 2: בדוק את גרסת הלקוח

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

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

שלב 3: מצא היכן המדיניות גרה

תדירות ההתחברות היא הגדרה של גישה מותנית במדיניות שמופנה לאפליקציית הארגון Azure VPN. היא לא נמצאית במשאב שער ה-VPN, לא בתצורת point-to-site ולא בפרופיל הלקוח. חפש את האפליקציה Azure VPN ברשימת המדיניות וקרא את פקידות ההפעלה.

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

שלב 4: עשה את החשבון

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

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

שלב 5: הפרד לוח זמנים מ-rekey

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

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

שלב 6: פרוס בלי הפתעות

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

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