يصف هذا القسم ميزة دعم الوكيل ل "أمان البيانات المختلطة". والغرض منه هو تكملة دليل النشر لأمن البيانات المختلطة من Cisco Webex، المتوفرعلى الرابط https://www.cisco.com/go/hybrid-data-securityالتالي: . في عملية نشر جديدة، يمكنك تكوين إعداد الوكيل على كل عقدة بعد تحميل تكوين HDS ISO وتركيبه على العقدة، وقبل تسجيل العقدة باستخدام سحابة Cisco Webex.

دعم البروكسي

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

تدعم عقد أمان البيانات المختلطة خيارات الوكيل التالية:

  • بدون وكيل—الإعداد الافتراضي إذا كنت لا تستخدم إعداد عقدة HDS Trust Store وتكوين الوكيل لدمج وكيل. لا يلزم تحديث الشهادة.

  • وكيل شفاف غير قابل للفحص—لم يتم تكوين العقد لاستخدام عنوان خادم وكيل معين ويجب ألا تتطلب أي تغييرات للعمل مع وكيلغير قابل للفحص. لا يلزم تحديث الشهادة.

  • نفق شفاف أو فحص الوكيل—لم يتم تكوين العقد لاستخدام عنوان خادم وكيل معين. لا يلزم إجراء تغييرات في تكوين HTTP أو HTTPS على العقد. ومع ذلك ، تحتاج العقد إلى شهادة جذر بحيث تثق في الوكيل. عادة ما تستخدم تكنولوجيا المعلومات فحص الوكلاء لفرض السياسات التي يمكن زيارة مواقع الويب عليها وأنواع المحتوى غير المسموح بها. يقوم هذا النوع من البروكسي بفك تشفير كل حركة المرور الخاصة بك (حتى HTTPS).

  • الوكيل الصريح—باستخدام الوكيلالصريح، يمكنك إخبار عقد HDS بالخادم الوكيل ونظام المصادقة الذي يجب استخدامه. لتكوين وكيل صريح، يجب إدخال المعلومات التالية على كل عقدة:

    1. IP الوكيل/FQDN—العنوان الذي يمكن استخدامه للوصول إلى جهاز الوكيل.

    2. منفذالوكيل—رقم منفذ يستخدمه الوكيل للاستماع إلى حركة المرور الوكيلة.

    3. بروتوكول الوكيل—استنادا إلى ما يدعمه الخادم الوكيل، اختر من بين البروتوكولات التالية:

      • HTTP—يعرض ويتحكم في جميع الطلبات التي يرسلها العميل.

      • HTTPS—يوفر قناة للخادم. يتلقى العميل شهادة الخادم ويتحقق من صحتها.

    4. نوع المصادقة—اختر من بين أنواع المصادقة التالية:

      • لا شيء- لا يلزم إجراء مزيد من المصادقة.

        متوفر إذا قمت بتحديد HTTP أو HTTPS كبروتوكول وكيل.

      • أساسي—يستخدم لوكيل مستخدم HTTP لتوفير اسم مستخدم وكلمة مرور عند تقديم طلب. يستخدم ترميز Base64.

        متوفر إذا قمت بتحديد HTTP أو HTTPS كبروتوكول وكيل.

        يتطلب منك إدخال اسم المستخدم وكلمة المرور على كل عقدة.

      • الملخص—يستخدم لتأكيد الحساب قبل إرسال معلومات حساسة. يطبق دالة تجزئة على اسم المستخدم وكلمة المرور قبل الإرسال عبر الشبكة.

        متوفر فقط إذا قمت بتحديد HTTPS كبروتوكول وكيل.

        يتطلب منك إدخال اسم المستخدم وكلمة المرور على كل عقدة.

مثال على عقد أمان البيانات المختلطة والوكيل

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

وضع دقة DNS الخارجي المحظور (تكوينات الوكيل الصريحة)

عند تسجيل عقدة أو التحقق من تكوين وكيل العقدة، تختبر العملية بحث DNS والاتصال بسحابة Cisco Webex. في عمليات النشر ذات تكوينات الوكيل الصريحة التي لا تسمح بدقة DNS الخارجية للعملاء الداخليين، إذا لم تتمكن العقدة من الاستعلام عن خوادم DNS، فإنها تنتقل تلقائيا إلى وضع حل DNS الخارجي المحظور. في هذا الوضع، يمكن متابعة تسجيل العقدة واختبارات اتصال الوكيل الأخرى.

متطلبات الخادم الوكيل

  • نحن ندعم رسميا حلول البروكسي التالية التي يمكن أن تتكامل مع عقد أمان البيانات المختلطة الخاصة بك.

    • وكيل شفاف - جهاز أمان الويب من Cisco (WSA).

    • وكيل صريح - الحبار.

      يمكن أن تتداخل بروكسيات الحبار التي تفحص حركة مرور HTTPS مع إنشاء websocket (wss:) اتصالات. كمحاولة للتغلب على هذه المشكلة راجع "Websocket لا يمكن الاتصال من خلال وكيل الحبار" في مشكلات الوكيل.

  • نحن ندعم مجموعات أنواع المصادقة التالية للوكلاء الصريحين:

    • لا توجد مصادقة باستخدام HTTP أو HTTPS

    • المصادقة الأساسية باستخدام HTTP أو HTTPS

    • تلخيص المصادقة باستخدام HTTPS فقط

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

  • يجب تكوين الشبكة التي تستضيف عقد HDS لإجبار حركة مرور TCP الصادرة على المنفذ 443 على التوجيه عبر الوكيل.

  • قد تتداخل الوكلاء الذين يفحصون حركة مرور الويب مع اتصالات مقبس الويب. في حالة حدوث هذه المشكلة، سيؤدي تجاوز (عدم فحص) حركة المرور إلى wbx2.com ciscospark.com إلى حل المشكلة.

تكوين عقدة HDS لتكامل الوكيل

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

قبل البدء

1

أدخل عنوان URL لإعداد عقدة HDS https://[HDS Node IP أو FQDN]/الإعداد في مستعرض ويب، وأدخل بيانات اعتماد المسؤول التي قمت بإعدادها للعقدة، ثم انقر فوق تسجيل الدخول.
2

انتقل إلى متجر الثقة والوكيل، ثم حدد خيارا:

  • بدون وكيل—الخيار الافتراضي قبل دمج وكيل. لا يلزم تحديث الشهادة.
  • وكيل شفاف غير قابل للفحص—لا يتم تكوين العقد لاستخدام عنوان خادم وكيلمحدد ويجب ألا تتطلب أي تغييرات للعمل مع وكيل غير قابل للفحص. لا يلزم تحديث الشهادة.
  • وكيل الفحص الشفاف—لا يتم تكوين العقد لاستخدام عنوان خادم وكيلمحدد. لا يلزم إجراء تغييرات في تكوين HTTPS على نشر أمان البيانات المختلط ، ومع ذلك ، تحتاج عقد HDS إلى شهادة جذر حتى تثق في الوكيل. عادة ما تستخدم تكنولوجيا المعلومات فحص الوكلاء لفرض السياسات التي يمكن زيارة مواقع الويب عليها وأنواع المحتوى غير المسموح بها. يقوم هذا النوع من البروكسي بفك تشفير كل حركة المرور الخاصة بك (حتى HTTPS).
  • الوكيل الصريح—باستخدام الوكيلالصريح، يمكنك إخبار العميل (عقد HDS) بالخادم الوكيل الذي يجب استخدامه، ويدعم هذا الخيار عدة أنواع من المصادقة. بعد تحديد هذا الخيار، يجب إدخال المعلومات التالية:

    1. IP الوكيل/FQDN—العنوان الذي يمكن استخدامه للوصول إلى جهاز الوكيل.

    2. منفذالوكيل—رقم منفذ يستخدمه الوكيل للاستماع إلى حركة المرور الوكيلة.

    3. بروتوكول الوكيل—اختر http (يعرض ويتحكم في جميع الطلبات التي يتم تلقيها من العميل) أو https (يوفر قناة للخادم ويتلقى العميل شهادة الخادم ويتحقق من صحتها). حدد خيارا استنادا إلى ما يدعمه الخادم الوكيل.

    4. نوع المصادقة—اختر من بين أنواع المصادقة التالية:

      • لا شيء- لا يلزم إجراء مزيد من المصادقة.

        متوفر لبروكسيات HTTP أو HTTPS.

      • أساسي—يستخدم لوكيل مستخدم HTTP لتوفير اسم مستخدم وكلمة مرور عند تقديم طلب. يستخدم ترميز Base64.

        متوفر لبروكسيات HTTP أو HTTPS.

        إذا اخترت هذا الخيار، فيجب عليك أيضا إدخال اسم المستخدم وكلمة المرور.

      • الملخص—يستخدم لتأكيد الحساب قبل إرسال معلومات حساسة. يطبق دالة تجزئة على اسم المستخدم وكلمة المرور قبل الإرسال عبر الشبكة.

        متوفر لبروكسيات HTTPS فقط.

        إذا اخترت هذا الخيار، فيجب عليك أيضا إدخال اسم المستخدم وكلمة المرور.

اتبع الخطوات التالية للحصول على وكيل فحص شفاف أو وكيل HTTP صريح مع مصادقة أساسية أو وكيل HTTPS صريح.
3

انقر فوق تحميل شهادة جذر أو شهادة كيان نهاية، ثم انتقل إلى اختيار الشهادة الجذر للوكيل.

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

انقر فوق التحقق من اتصال الوكيل لاختبار اتصال الشبكة بين العقدة والوكيل.

إذا فشل اختبار الاتصال، فسترى رسالة خطأ توضح السبب وكيفية تصحيح المشكلة.

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

بعد اجتياز اختبار الاتصال، بالنسبة إلى الوكيل الصريح الذي تم تعيينه على https فقط، قم بتشغيل مفتاح التبديل إلى توجيه جميع طلبات https للمنفذ 443/444 من هذه العقدة عبر الوكيلالصريح. يتطلب هذا الإعداد 15 ثانية ليصبح ساري المفعول.
6

انقر فوق تثبيت كافة الشهادات في مخزن الثقة (يظهر لوكيل HTTPS صريح أو وكيل فحص شفاف) أو إعادة تشغيل (يظهر لوكيل HTTP صريح)، واقرأ المطالبة، ثم انقر فوق تثبيت إذا كنت مستعدا.

تتم إعادة تشغيل العقدة في غضون بضع دقائق.
7

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

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

التصرف التالي

كرر تكوين الوكيل على كل عقدة في مجموعة أمان البيانات المختلطة.

إيقاف تشغيل وضع دقة DNS الخارجي المحظور

عند تسجيل عقدة أو التحقق من تكوين وكيل العقدة، تختبر العملية بحث DNS والاتصال بسحابة Cisco Webex. إذا تعذر على خادم DNS الخاص بالعقدة حل أسماء DNS العامة، فستنتقل العقدة تلقائيا إلى وضع حل DNS الخارجي المحظور.

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

قبل البدء

تأكد من أن خوادم DNS الداخلية يمكنها حل أسماء DNS العامة، وأن العقد يمكنها التواصل معها.

1

في مستعرض ويب، افتح واجهة عقدة أمان البيانات المختلطة (عنوان IP/الإعداد، على سبيل المثال، أدخل بيانات اعتماد المسؤول التي قمت بإعدادها للعقدة، https://192.0.2.0/setup), ثم انقر فوق تسجيل الدخول.
2

انتقل إلى نظرة عامة (الصفحة الافتراضية).

عند تمكينه، يتم تعيين دقة DNS الخارجية المحظورة إلى نعم.
3

انتقل إلى صفحة متجر الثقة والوكيل .
4

انقر فوق التحقق من اتصال الوكيل.

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

التصرف التالي

كرر اختبار اتصال الوكيل على كل عقدة في مجموعة أمان البيانات المختلطة.

يصف هذا القسم ميزة دعم الوكيل ل Webex Video Mesh. والغرض منه هو تكملة دليل النشر الخاص بشبكة الفيديو Webex من Cisco، المتوفر على العنوان التالي https://www.cisco.com/go/video-mesh: . في عملية نشر جديدة، يمكنك تكوين إعداد الوكيل على كل عقدة بعد نشر برنامج Video Mesh على بيئة جهاز ظاهري، وقبل تسجيل العقدة باستخدام سحابة Cisco Webex.

دعم الوكيل لشبكة فيديو Cisco Webex

تدعم Cisco Webex Video Mesh الوكلاء الصريحين والشفافين وغير المميزين. يمكنك ربط هذه البروكسيات بنشر Webex Video Mesh بحيث يمكنك تأمين حركة المرور ومراقبتها من المؤسسة إلى السحابة. ترسل هذه الميزة إشارات المرور المستندة إلى https وإدارتها إلى الوكيل. بالنسبة للوكلاء الشفافين، تتم إعادة توجيه طلبات الشبكة من عقد Video Mesh إلى وكيل معين من خلال قواعد توجيه شبكة المؤسسة. يمكنك استخدام واجهة مسؤول Webex Video Mesh لإدارة الشهادات وحالة الاتصال العامة بعد تنفيذ الوكيل باستخدام العقد.

لا تنتقل الوسائط عبر الوكيل. لا يزال يتعين عليك فتح المنافذ المطلوبة لتدفقات الوسائط للوصول إلى السحابة مباشرة.

يتم دعم أنواع البروكسي التالية بواسطة Video Mesh:

  • الوكيل الصريح (الفحص أو عدم الفحص)—باستخدام الوكيل الصريح، يمكنك إخبار العميل (عقد شبكة الفيديو) بالخادم الوكيل الذي يجب استخدامه. يدعم هذا الخيار أحد أنواع المصادقة التالية:

    • لا شيء - لا يلزم إجراء مزيد من المصادقة. (بالنسبة إلى وكيل HTTP أو HTTPS الصريح.)

    • أساسي—يستخدم لوكيل مستخدم HTTP لتوفير اسم مستخدم وكلمة مرور عند تقديم طلب، ويستخدم ترميز Base64. (بالنسبة إلى وكيل HTTP أو HTTPS الصريح.)

    • Digest—يستخدم لتأكيد هوية الحساب قبل إرسال معلومات حساسة، ويطبق وظيفة التجزئة على اسم المستخدم وكلمة المرور قبل الإرسال عبر الشبكة. (بالنسبة إلى وكيل HTTPS الصريح.)

    • NTLM—مثل Digest، يتم استخدام NTLM لتأكيد هوية الحساب قبل إرسال معلومات حساسة. يستخدم بيانات اعتماد Windows بدلا من اسم المستخدم وكلمة المرور. يتطلب نظام المصادقة هذا عمليات تبادل متعددة لإكمالها. (بالنسبة لوكيل HTTP الصريح.)

  • وكيل شفاف (غير قابل للفحص)—لا يتم تكوين عقد شبكة الفيديو لاستخدام عنوان خادم وكيل معين ويجب ألا تتطلب أي تغييرات للعمل مع وكيل غير قابل للفحص.

  • الوكيل الشفاف (التفتيش)—لا يتم تكوين عقد شبكة الفيديو لاستخدام عنوان خادم وكيل محدد. لا يلزم إجراء تغييرات في تكوين http (s) على Video Mesh، ومع ذلك، تحتاج عقد Video Mesh إلى شهادة جذر حتى تثق في الوكيل. عادة ما تستخدم تكنولوجيا المعلومات فحص الوكلاء لفرض السياسات المتعلقة بمواقع الويب التي يمكن زيارتها وأنواع المحتوى غير المسموح بها. يقوم هذا النوع من الوكيل بفك تشفير كل حركة المرور الخاصة بك (حتى https).

الشكل رقم 1. مثال على عقد شبكة فيديو Webex والوكيل.

يوضح هذا الرسم التخطيطي مثالا على الاتصال بين شبكةفيديو Webex والشبكة والوكيل. بالنسبة لخيارات وكيل الفحص الشفاف والفحص الصريح ، يجب تثبيت نفس شهادة الجذر على الوكيل وعلى عقد Video Mesh.

متطلبات دعم الوكيل لشبكة فيديو Webex

  • نحن ندعم رسميا حلول البروكسي التالية التي يمكن أن تتكامل مع عقد Webex Video Mesh الخاصة بك .

    • جهاز أمان الويب (WSA) من Cisco للوكيل الشفاف

    • الحبار للوكيل الصريح

  • للحصول على وكيل صريح أو وكيل فحص شفاف يقوم بفحص (فك تشفير حركة المرور)، يجب أن يكون لديك نسخة من شهادة جذر الوكيل التي ستحتاج إلى تحميلها إلى متجر ثقة عقدة Webex Video Mesh على واجهة الويب.

  • نحن ندعم مجموعات أنواع البروكسي والمصادقة الصريحة التالية:

    • لا توجد مصادقة باستخدام http و https

    • المصادقة الأساسية باستخدام http و https

    • تلخيص المصادقة باستخدام https فقط

    • مصادقة NTLM باستخدام http فقط

  • بالنسبة للوكلاء الشفافين، يجب عليك استخدام جهاز التوجيه/المحول لإجبار حركة مرور HTTPS/443 على الانتقال إلى الوكيل. يمكنك أيضا إجبار Web Socket/444 على الانتقال إلى الوكيل. (يستخدم مقبس الويب https.) يعتمد المنفذ 444 على إعداد الشبكة. إذا لم يتم توجيه المنفذ 444 عبر الوكيل، فيجب أن يكون مفتوحا مباشرة من العقدة إلى السحابة.

    يتطلب Webex Video Mesh اتصالات مقبس ويب بالخدمات السحابية ، بحيث تعمل العقد بشكل صحيح. عند الفحص الصريح ووكلاء الفحص الشفاف، يتم تغيير رؤوس http المطلوبة لاتصال websocket مناسب وتفشل اتصالات websocket.

    العرض عند حدوث ذلك على المنفذ 443 (مع تمكين وكيل الفحص الشفاف) هو تحذير ما بعد التسجيل في مركز التحكم: "Webex Video Mesh SIP الاتصال لا يعمل بشكل صحيح." يمكن أن يحدث نفس التنبيه لأسباب أخرى عند عدم تمكين الوكيل. عند حظر رؤوس websocket على المنفذ 443، لا تتدفق الوسائط بين التطبيقات وعملاء SIP.

    إذا لم تكن الوسائط تتدفق، فغالبا ما يحدث هذا عند فشل حركة مرور https من العقدة عبر المنفذ 444 أو المنفذ 443:

    • لا يقوم الوكيل بالتفتيش، ولكن لا يسمح الوكيل بحركة مرور المنفذ 444.

    • يسمح الوكيل بحركة مرور المنفذ 443 أو المنفذ 444 ، ولكنه وكيل فحص ويكسر websocket.

    لتصحيح هذه المشكلات، قد تضطر إلى "تجاوز" أو "ربط" (تعطيل الفحص) على المنفذين 444 و443 من أجل: *.wbx2.com و*.ciscospark.com.

تكوين Webex عقدة شبكة الفيديو لتكامل الوكيل

استخدم هذا الإجراء لتحديد نوع الوكيل الذي تريد دمجه مع Webex Video Mesh. إذا اخترت وكيل فحص شفاف أو وكيل صريح، فيمكنك استخدام واجهة العقدة لتحميل الشهادة الجذر وتثبيتها، والتحقق من اتصال الوكيل، واستكشاف أي مشكلات محتملة وإصلاحها.

قبل البدء

1

أدخل عنوان URL لإعداد Webex Video Mesh https://[IP أو FQDN/setup في مستعرض ويب، وأدخل بيانات اعتماد المسؤول التي قمت بإعدادها للعقدة، ثم انقر فوق تسجيل الدخول.
2

انتقل إلى متجر الثقة والوكيل، ثم حدد خيارا:

  • بدون وكيل—الخيار الافتراضي قبل دمج وكيل. لا يلزم تحديث الشهادة.
  • وكيل شفاف غير قابل للفحص—لم يتم تكوين عقد شبكة الفيديو لاستخدام عنوان خادم وكيل معين ويجب ألا تتطلب أي تغييرات للعمل مع وكيلغير قابل للفحص. لا يلزم تحديث الشهادة.
  • وكيلالفحص الشفاف—لا يتم تكوين عقد شبكة الفيديو لاستخدام عنوان خادم وكيل محدد. لا توجد تغييرات في تكوين http (s) ضرورية على شبكة الفيديو ؛ ومع ذلك ، تحتاج عقد شبكة الفيديو إلى شهادة جذر حتى تثق في الوكيل. عادة ما تستخدم تكنولوجيا المعلومات فحص الوكلاء لفرض السياسات المتعلقة بمواقع الويب التي يمكن زيارتها وأنواع المحتوى غير المسموح بها. يقوم هذا النوع من الوكيل بفك تشفير كل حركة المرور الخاصة بك (حتى https).
  • الوكيل الصريح—باستخدام الوكيلالصريح، يمكنك إخبار العميل (عقد شبكة الفيديو) بالخادم الوكيل الذي يجب استخدامه، ويدعم هذا الخيار عدة أنواع من المصادقة. بعد تحديد هذا الخيار، يجب إدخال المعلومات التالية:

    1. IP الوكيل/FQDN—العنوان الذي يمكن استخدامه للوصول إلى جهاز الوكيل.

    2. منفذالوكيل—رقم منفذ يستخدمه الوكيل للاستماع إلى حركة المرور الوكيلة.

    3. بروتوكول الوكيل—اختر http (تقوم شبكة الفيديو بنفق حركة مرور https الخاصة بها من خلال وكيل http ) أو https (تستخدم حركة المرور من عقدة شبكة الفيديو إلى الوكيل بروتوكولhttps ). حدد خيارا استنادا إلى ما يدعمه الخادم الوكيل.

    4. اختر من بين أنواع المصادقة التالية، وفقا لبيئة الوكيل الخاصة بك:

      الخيار

      الاستخدام

      لا شيء

      اختر لبروكسيات HTTP أو HTTPS الصريحة التي لا توجد فيها طريقة مصادقة.

      أساسي

      متوفر لبروكسيات HTTP أو HTTPS الصريحة.

      يستخدم لوكيل مستخدم HTTP لتوفير اسم مستخدم وكلمة مرور عند تقديم طلب، ويستخدم ترميز Base64.

      هضم

      متوفر لبروكسيات HTTPS الصريحة فقط.

      يستخدم لتأكيد الحساب قبل إرسال المعلومات الحساسة، ويطبق وظيفة التجزئة على اسم المستخدم وكلمة المرور قبل الإرسال عبر الشبكة.

      NTLM

      متوفر لبروكسيات HTTP الصريحة فقط.

      مثل Digest ، يستخدم لتأكيد الحساب قبل إرسال معلومات حساسة. يستخدم بيانات اعتماد Windows بدلا من اسم المستخدم وكلمة المرور.

      إذا اخترت هذا الخيار، فأدخل مجال Active Directory الذي يستخدمه الوكيل للمصادقة في حقل مجال NTLM. أدخل اسم محطة العمل الوكيل (يشار إليه أيضا باسم حساب محطة عمل أو حساب جهاز) ضمن مجال NTLM المحدد في حقل محطة عمل NTLM.

اتبع الخطوات التالية للحصول على فحص شفاف أو وكيل صريح.
3

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

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

للفحص الشفاف أو الوكلاء الصريحين، انقر فوق التحقق من اتصال الوكيل لاختبار اتصال الشبكة بين عقدة شبكة الفيديو والوكيل.

إذا فشل اختبار الاتصال، فسترى رسالة خطأ توضح السبب وكيفية تصحيح المشكلة.
5

بعد اجتياز اختبار الاتصال، بالنسبة للوكيل الصريح، قم بتشغيل مفتاح التبديل إلى توجيه جميع طلبات https للمنفذ 443/444 من هذه العقدة عبر الوكيلالصريح. يتطلب هذا الإعداد 15 ثانية ليصبح ساري المفعول.
6

انقر فوق تثبيت كافة الشهادات في مخزن الثقة (يظهر كلما تمت إضافة شهادة جذر أثناء إعداد الوكيل) أو إعادة التشغيل (يظهر إذا لم تتم إضافة شهادة الجذر)، واقرأ المطالبة، ثم انقر فوق تثبيت إذا كنت مستعدا.

تتم إعادة تشغيل العقدة في غضون بضع دقائق.
7

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

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

مشكلات البروكسي

ما هي حركة المرور التي تمر عبر الوكيل

بالنسبة إلى شبكة الفيديو، لا تجتاز الوسائط الوكيل. ترسل هذه الميزة إشارات المرور المستندة إلى https وإدارتها إلى الوكيل. لا يزال يتعين عليك فتح المنافذ المطلوبة لتدفقات الوسائط للوصول إلى السحابة مباشرة.

لم يتم تمكين منفذ TCP 444 على الوكيل

يعد هذا المنفذ أحد متطلبات Video Mesh، لأن Video Mesh يستخدم هذا المنفذ للوصول إلى الخدمات المستندة إلى مجموعة النظراء التي يجب استخدامها للعمل بشكل صحيح. يجب إجراء استثناء وكيل لهذا المنفذ وأي منفذ كما هو موثق في دليل نشر شبكة الفيديو ومتطلبات الشبكة لخدمات Webex Teams.

لا يتم دعم تصفية إشارات المرور حسب عنوان IP لأن عناوين IP المستخدمة من قبل حلولنا ديناميكية وقد تتغير في أي وقت.

لا توجد شهادة جذر مثبتة

عندما تتحدث العقد إلى وكيل صريح، يجب تثبيت الشهادة الجذر وإدخال استثناء لعنوان URL هذا على جدار الحماية.

فشل التحقق من الاتصال

إذا تم اجتياز فحص اتصال الوكيل واكتمال تثبيت الوكيل، فقد تظل عمليات التحقق من الاتصال في صفحة النظرة العامة تفشل للأسباب التالية:

  • يقوم الوكيل بفحص حركة المرور التي لا تذهب إلى webex.com.

  • يقوم الوكيل بحظر نطاقات أخرى غير webex.com.

تفاصيل المصادقة غير صحيحة

بالنسبة للوكلاء الذين يستخدمون آلية مصادقة، تأكد من إضافة تفاصيل المصادقة الصحيحة في العقدة.

الازدحام على الوكيل

يمكن أن يتسبب الازدحام على الوكيل في تأخير وانخفاض حركة المرور إلى السحابة. تحقق من بيئة الوكيل لمعرفة ما إذا كان اختناق حركة المرور مطلوبا.

لا يمكن ل Websocket الاتصال من خلال وكيل الحبار

يمكن أن تتداخل بروكسيات الحبار التي تفحص حركة مرور HTTPS مع إنشاء websocket (wss:) الاتصالات التي يتطلبها أمان البيانات المختلط وشبكة فيديو Webex. قد ترى سلسلة من التحذيرات في السجلات مثل "إعادة توصيل WebSocket ..." كما تحاول العقدة الوصول إلى سحابة Webex. جرب تكوين Squid التالي، استنادا إلى إصدار Squid الخاص بك، لجعل الوكيل يتجاهل wss: حركة المرور للتشغيل السليم.

الحبار 4 و 5

أضف الرمز on_unsupported_protocol توجيه إلى squid.conf:

on_unsupported_protocol tunnel all

الحبار 3.5.27

لقد اختبرنا بنجاح أمان البيانات المختلط مع إضافة القواعد التالية إلى squid.conf. تخضع هذه القواعد للتغيير أثناء تطوير الميزات وتحديث سحابة Webex.

acl wssMercuryConnection ssl::server_name_regex mercury-connection

ssl_bump splice wssMercuryConnection

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all
ssl_bump stare step2 all
ssl_bump bump step3 all

لقد اختبرنا بنجاح شبكة الفيديو مع القواعد التالية المضافة إلى squid.conf. (تتطلب شبكة الفيديو اثنين من acls إضافية مقارنة بأمان البيانات المختلط.) تخضع هذه القواعد للتغيير أثناء تطوير الميزات وتحديث سحابة Webex.

acl wssMercuryConnection ssl::server_name_regex mercury-connection
acl ciscoCloud1 ssl::server_name .wbx2.com
acl ciscoCloud2 ssl::server_name .ciscospark.com

ssl_bump splice wssMercuryConnection
ssl_bump splice ciscoCloud1
ssl_bump splice ciscoCloud2

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all
ssl_bump stare step2 all
ssl_bump bump step3 all