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: افصل الجدول عن إعادة المفتاح

إعادة مفتاح IPsec واكتشاف الند الميت ومهل الخمول تنتج انقطاعات غير منتظمة مرتبطة بحجم الحركة أو بالصمت، لا بساعة إيقاف. المستخدم الذي ينقطع في منتصف نقل والمستخدم الذي ينقطع بعد غداء خامل يصفان آليتين مختلفتين. اسأل عما كان يفعله المستخدم في الدقيقة السابقة للانقطاع.

مشاكل الشهادة تبدو مختلفة تمامًا: فشل العميل في الاتصال بدلاً من فقدان جلسة عاملة، والفشل فوري. طلب MFA لا يكتمل أبدًا يظهر كتعلّق، لا كانقطاع ساعة نظيف يتبعه اتصال ناجح.

الخطوة 6: انشر دون مفاجأة

أعلن تحديث العميل قبل أن يصل إلى المستخدمين عبر المتجر، لأن تغيير السلوك يأتي مع العميل. اختر التكرار من المتطلب: قيمة تغطي يوم العمل من أجل سهولة الاستخدام، أو قيمة قصيرة إذا كان حاسوب مفقود يجب أن يفقد الوصول سريعًا. سجّل أي متطلب انتصر، لأن الإعداد نفسه ينتج الحماية والشكوى معًا. ثم أكّد الاختيار على جهاز يشغّل الإصدار الجديد بدلاً من استنتاجه من تجربة بالإصدار القديم.

احفظ الرسالة والإصدار وقيمة السياسة والفاصل المقاس في ملاحظة واحدة. تلك السجلات تجيب عن البلاغ التالي في دقيقة بدلاً من إعادة بناء.