Azure VPN Client 3.4 هر ساعت قطع می‌شود: تکرار ورود

یک کاربر وصل می‌شود، کار می‌کند، و سپس هر ساعت یک بار با پیام پایان یافتن احراز هویت در Microsoft Entra قطع می‌شود. اتصال مجدد کار می‌کند و چرخه مانند کرونومتر تکرار می‌شود. در یک دروازهٔ point-to-site که چیزی در آن مستقر نشده، این الگو اعتبارنامه را نشان می‌دهد و نه تونل. کلاینت Azure VPN 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: بدون سرگرمی استقرار دهید

به‌روزرسانی کلاینت را پیش از اینکه از طریق فروشگاه به کاربران برسد اعلام کنید، زیرا تغییر رفتار همراه کلاینت ارائه می‌شود. تکرار را براساس نیاز انتخاب کنید: مقداری که روز کاری را پوشش می‌دهد برای استفادهٔ راحت، یا مقداری کوتاه اگر لپ‌تاپ گم‌شده باید سریع دسترسی را از دست بدهد. یادداشت کنید کدام نیاز برنده شد، زیرا همان تنظیم هم حمایت را می‌سازد و هم شکایت. سپس انتخاب را روی دستگاهی با نسخهٔ جدید تأیید کنید، به‌جای اینکه از یک پایلوت با نسخهٔ قدیمی استنتاج کنید.

پیام، نسخه، مقدار سیاست و بازهٔ اندازه‌گیری‌شده را در یک یادداشت نگه دارید. این سابقه به گزارش بعدی در یک دقیقه پاسخ می‌دهد، نه با بازسازی.