يتم قطع اتصال Secure Access بشكل متقطع خلف جدران الحماية الخاصة بالشركات من خلال أخطاء IdleTimeout

• مسألة
• البيئة
• قرار
• الخطوة 1: تنفيذ تكوين المخزن المؤقت MX TTL
• الخطوة 2: تكوين إستثناءات المجال المطلوبة
• الخطوة 3: التحقق من بدلات المنفذ والبروتوكول
• الخطوة 4: مراقبة دقة الوضوح والتحقق منها
• السبب
• المحتوى ذي الصلة

---

مسألة

يواجه عملاء Cisco Secure Access انقطاعا متقطعا لإعادة الاتصال بشكل فوري عند توصيل نقاط النهاية بشبكة الشركة. تحدث حالات عدم الاتصال بشكل عشوائي، حيث تتم إعادة اتصال العميل تلقائيا بعد مرور حوالي 5 ثوان. ويتم ملاحظة هذا السلوك عندما يتم وكيل حركة مرور الإنترنت عبر الوصول إلى وضع عدم الثقة (ZTA) لتأمين الوصول من نقاط النهاية الموجودة خلف أجهزة Cisco FirePower و Meraki MX.

يلتقط سجل أحداث Windows أخطاء "idleTimeout" معينة أثناء أحداث قطع الاتصال هذه. لا يحدث نمط الانفصال عند اتصال المستخدمين باتصالات الإنترنت المنزلية، مما يشير إلى أن المشكلة تتعلق تحديدا بالبنية الأساسية لشبكة الشركة.

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

البيئة

• Cisco Secure Access - نشر الميزات

• برنامج عميل الوصول الآمن إلى الإنترنت (SIA) من Cisco

• بنية تحتية لشبكة الشركة مع أجهزة الأمان FirePOWER من Cisco

• أجهزة أمان Meraki MX في مسار الشبكة

• تكوين وكيل الوصول إلى الثقة صفر (ZTA) لحركة مرور الإنترنت لتأمين الوصول

• نقاط نهاية Windows مع إمكانية تسجيل الأحداث

• سيناريوهات اتصال مختلطة: شبكة الشركات (المتأثرة) ووصلات الإنترنت المنزلية (غير المتأثرة)

قرار

وتضمن الحل إجراء تغييرات في التكوين على جهاز Meraki MX وضمان إستثناءات المجال وبدلات المنفذ المناسبة لتكامل الوصول الآمن.

الخطوة 1: تنفيذ تكوين المخزن المؤقت MX TTL

قم بتكوين مخزن مؤقت MX TTL على جهاز Meraki MX لمعالجة سلوك التخزين المؤقت ل DNS TTL الذي كان يساهم في مشاكل قطع الاتصال المتقطع. يعمل تغيير التكوين هذا على حل تعارضات التوقيت بين التخزين المؤقت لدقة DNS وتوقعات اتصال عميل Secure Access.

الخطوة 2: تكوين إستثناءات المجال المطلوبة

ضمنت هذا مجال بشكل صحيح استثنيت من الإعتراض وأضفت إلى قوائم غير مشفرة على كل من Cisco FirePower و Meraki MX أداة:

• ztna.sse.cisco.com

• zpc.sse.cisco.com

• مجالات خدمة الوصول الآمن الإضافية كما هو محدد في تكوين السياسة

الخطوة 3: التحقق من بدلات المنفذ والبروتوكول

قم بتكوين البنية الأساسية لجدار حماية الشركة للسماح بمنافذ وبروتوكولات الوصول الآمن المطلوبة من خلال كل من أجهزة FirePOWER و Meraki MX. تأكد من معالجة حركة المرور إلى المنفذ 443 لنقاط نهاية خدمة الوصول الآمن بشكل صحيح دون تدخل من فحص الأمان الذي قد يتسبب في ظروف المهلة.

الخطوة 4: مراقبة دقة الوضوح والتحقق منها

بعد تنفيذ تكوين المخزن المؤقت ل MX TTL، قم بمراقبة سلوك عميل Secure Access لعدة أيام للتأكد من توقف نمط قطع الاتصال المتقطع وإعادة الاتصال.

السبب

حدث قطع الاتصال المتقطع بسبب تعارضات سلوك التخزين المؤقت ل DNS (مدة البقاء) بين البنية الأساسية لشبكة الشركة وتوقعات خدمة الوصول الآمن. كشف تحليل Cisco الهندسي عن أختلاف قيم DNS TTL بسبب سلوك ذاكرة التخزين المؤقت للحل، ومن المتوقع أن يحدث سلوك بديل لعناوين IP بسبب آليات موازنة الأحمال في بنية خدمة الوصول الآمن.

عندما قامت أجهزة شبكة الشركة (Cisco FirePower و Meraki MX) بمعالجة استجابات DNS لنقاط النهاية الخاصة بالوصول الآمن، تسبب التخزين المؤقت ومعالجة TTL في عدم تطابق في التوقيتات مما أدى إلى شروط "idleTimeout". تسبب تعارض التوقيت هذا في تفسير عميل Secure Access للاتصال على أنه خامل وبدء دورات قطع الاتصال/إعادة الاتصال.

كانت المشكلة خاصة ببيئات شبكة الشركة لأن إتصالات الإنترنت المنزلية لا تنفذ عادة نفس المستوى من التخزين المؤقت ل DNS وفحص حركة مرور البيانات الذي يمكن أن يتعارض مع إدارة حالة اتصال عميل Secure Access.

المحتوى ذي الصلة

• الدعم الفني والتنزيلات من Cisco

محفوظات المراجعة

المراجعة	تاريخ النشر	التعليقات
1.0	31-Aug-2026	الإصدار الأولي