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

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

• نريد شرحها، حتى تفهم دورها في النشر المختلط وتشعر بالاطمئنان.

• إنها متطلبات أساسية إلزامية تضمن النشر الآمن بين السحابة والبيئة الداخلية الخاصة بك.

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

• بعد معالجة هذه العناصر في بيئتك، ستتم بقية تكوين الخدمات المختلطة بسلاسة.

يسمح نشر زوج Expressway-C و Expressway-E بإجراء مكالمات من وإلى الإنترنت باستخدام تقنيات اجتياز جدار الحماية . هذا النشر هو ما يجعل التحكم في المكالمات المحلية آمنًا ويربطه بـ Webex.

لا يتطلب Expressway-C و Expressway-E فتح أي منفذ وارد في جدار الحماية للمنطقة المنزوعة السلاح (DMZ) بسبب بنية اجتياز جدار الحماية. ولكن يجب فتح منافذ إشارات TCP SIP ومنافذ وسائط UDP داخليًا على جدار حماية الإنترنت للسماح للمكالمات الواردة بالمرور. يجب إتاحة الوقت لفتح المنفذ المناسب على جدار الحماية الخاص بالمؤسسة.

تظهر بنية اجتياز جدار الحماية في الرسم التخطيطي التالي:

على سبيل المثال، بالنسبة للمكالمات الواردة بين الشركات (B2B) باستخدام بروتوكول SIP، يجب فتح منافذ TCP 5060 و5061 (يتم استخدام 5061 لـ SIP TLS) على جدار الحماية الخارجي، جنبًا إلى جنب مع منافذ وسائط UDP المستخدمة لخدمات مثل الصوت والفيديو ومشاركة المحتوى والفيديو المزدوج وما إلى ذلك. تعتمد منافذ الوسائط التي سيتم فتحها على عدد المكالمات المتزامنة وعدد الخدمات.

يمكنك تكوين منفذ الاستماع SIP على Expressway ليكون بأي قيمة بين 1024 إلى 65534. في الوقت نفسه، يجب الإعلان عن هذه القيمة ونوع البروتوكول في DNS SRV السجلات العامة، ويجب فتح نفس القيمة على جدار حماية الإنترنت.

على الرغم من أن معيار SIP TCP هو 5060 ولSIP TLS 5061، فلا شيء يمنع استخدام المنافذ المختلفة، كما يوضح المثال التالي.

مثال

في هذا المثال، نفترض أن المنفذ 5062 يُستخدم لمكالمات SIP TLS الواردة.

يبدو DNS SRV سجل مجموعة من خادمي Expressway كما يلي:

_رشفات. موقع خدمة تأجير السيارات _tcp.example.com:

priority = 10

weight = 10

port = 5062

اسم مضيف svr = us-expe1.example.com

_رشفات. موقع خدمة تأجير السيارات _tcp.example.com:

priority = 10

weight = 10

port = 5062

اسم مضيف svr = us-expe2.example.com

تعني هذه السجلات أنه يتم توجيه المكالمات إلى us-expe1.example.com وus-expe2.example.com مع مشاركة الأحمال المتساوية (الأولوية والوزن) باستخدام TLS كنوع النقل و5062 كرقم منفذ الاستماع.

يجب على الجهاز الخارجي للشبكة (على الإنترنت) والذي يقوم بإجراء مكالمة SIP لمستخدم مجال الشركة (user1@example.com) الاستعلام عن DNS لفهم نوع النقل الذي يجب استخدامه ورقم المنفذ وكيفية تحميل/مشاركة حركة المرور وخوادم SIP التي سيتم إرسال المكالمة إليها.

إذا كان إدخال DNS يتضمن _sips. _tcp، يحدد الإدخال SIP TLS.

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

تظهر مصافحة TLS في الرسم التخطيطي التالي:

ومع ذلك، تنص مواصفات TLS على أنه يمكن للخادم أيضًا التحقق من شهادة العميل عن طريق إرسال رسالة طلب شهادة إلى العميل أثناء بروتوكول مصافحة TLS. هذه الرسالة مفيدة في الاتصال من خادم إلى خادم، مثل الاتصال الذي تم إنشاؤه بين Expressway-E وسحابة Webex. يُطلق على هذا المفهوم اسم TLS مع المصادقة المتبادلة وهو مطلوب عند الدمج مع Webex.

يقوم كل من الطرف المتصل والمطلوب بالتحقق من شهادة الطرف الآخر، كما يوضح الرسم البياني التالي:

تتحقق السحابة من هوية Expressway، وتتحقق Expressway من هوية السحابة. على سبيل المثال، إذا كانت هوية السحابة في الشهادة (CN أو SAN) لا تتطابق مع ما تم تكوينه على Expressway، يتم قطع الاتصال.

في حالة تشغيل المصادقة المتبادلة، يطلب Expressway-E دائمًا شهادة العميل. ونتيجة لذلك، لن يعمل Mobile و Remote Access (MRA)، لأنه في معظم الحالات لا يتم نشر الشهادات على عملاء Jabber . في سيناريو الأعمال التجارية، إذا لم يكن الكيان المتصل قادرًا على توفير شهادة، يتم قطع الاتصال بالمكالمة.

نوصي باستخدام قيمة أخرى غير 5061 لـ TLS مع المصادقة المتبادلة، مثل المنفذ 5062. تستخدم خدمات Webex Hybrid نفس سجل SIP TLS المستخدم في B2B. في حالة المنفذ 5061، لن تعمل بعض الخدمات الأخرى التي لا يمكنها توفير شهادة عميل TLS.

إذا كان السجل الحالي مستخدمًا بالفعل للاتصالات بين الشركات، فإننا نوصي بتحديد نطاق فرعي لنطاق الشركة كوجهة SIP في Control Hub، وبالتالي DNS SRV سجل عام، على النحو التالي:

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

حركة المرور بين الشركات والأجهزة المحمولة Remote Access وWebex على نفس زوج Expressway

تستخدم مكالمات الأعمال بين الشركات (B2B) والمكالمات المحمولة و Remote Access (MRA) المنفذ 5061 لـ SIP TLS، وتستخدم حركة مرور Webex المنفذ 5062 لـ SIP TLS مع المصادقة المتبادلة.

التحقق من ملكية النطاق هو جزء من التحقق من الهوية. التحقق من النطاق هو إجراء أمني وفحص هوية تنفذه سحابة Webex لإثبات أنك الشخص الذي تقوله.

يتم التحقق من الهوية على مرحلتين:

1. التحقق من ملكية المجال. تتضمن هذه الخطوة ثلاثة أنواع من المجالات وهي عبارة عن فحص تحقق لمرة واحدة:

   • نطاق البريد الإلكتروني

   • مجال DNS السريع

   • مجال URI للدليل

2. التحقق من ملكية اسم Expressway-E DNS. يتم تنفيذ هذه الخطوة من خلال تنفيذ TLS مع المصادقة المتبادلة وتتضمن استخدام الشهادات العامة على كل من السحابة والطريق السريع. على عكس التحقق من هوية المجال، يتم تنفيذ هذه الخطوة أثناء أي مكالمة يتم إجراؤها واستقبالها من السحابة.

أهمية التحقق من ملكية النطاق

تقوم سحابة Webex بإجراء فحص ملكية المجال لفرض الأمان. تعد سرقة الهوية أحد التهديدات المحتملة إذا لم يتم إجراء هذا الفحص.

توضح القصة التالية ما قد يحدث إذا لم يتم إجراء فحص ملكية النطاق.

تشتري شركة لديها نطاق DNS مضبوط على «hacker.com» خدمات Webex الهجينة. تستخدم شركة أخرى، بنطاقها الخاص المحدد على «example.com»، أيضًا خدمات مختلطة. أحد المديرين العامين لشركة Example.com يدعى جين رو ولديه دليل URI jane.roe@example.com.

يقوم مسؤول شركة Hacker.com بتعيين أحد عناوين URL الخاصة بدليلها إلى jane.roe@example.com وعنوان البريد الإلكتروني إلى jane.roe@hacker.com. يمكنها القيام بذلك لأن السحابة لا تتحقق من نطاق SIP URI في هذا المثال.

بعد ذلك، تقوم بتسجيل الدخول إلى تطبيق Webex باستخدام jane.roe@hacker.com. ونظرًا لأنها تمتلك النطاق، تتم قراءة رسالة التحقق الإلكترونية والرد عليها، ويمكنها تسجيل الدخول. أخيرًا، تقوم بإجراء مكالمة مع زميل لها، جون دو، عن طريق الاتصال بـ john.doe@example.com من تطبيق Webex الخاص بها. يجلس جون في مكتبه ويرى مكالمة على جهاز الفيديو الخاص به قادمة من jane.roe@example.com؛ هذا هو دليل URI المرتبط بحساب البريد الإلكتروني هذا.

«إنها في الخارج»، كما يعتقد. «قد تحتاج إلى شيء مهم.» يجيب على الهاتف، وتطلب جين رو المزيفة وثائق مهمة. وتوضح أن جهازها معطل، ولأنها مسافرة، تطلب منه إرسال المستندات إلى عنوان بريدها الإلكتروني الخاص، jane.roe@hacker.com. بهذه الطريقة، تدرك الشركة فقط بعد عودة جين رو إلى المكتب أنه تم تسريب معلومات مهمة خارج الشركة.

تمتلك شركة Example.com العديد من الطرق للحماية من المكالمات الاحتيالية القادمة من الإنترنت، ولكن إحدى مسؤوليات سحابة Webex هي التأكد من أن هوية أي شخص يتصل من Webex صحيحة وغير مزيفة.

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

ولضمان هذه الملكية، يلزم اتخاذ خطوتي التحقق من المجال:

1. أثبت أن الشركة تمتلك مجال البريد الإلكتروني ومجال Expressway-E ومجال الدليل URI.

   • يجب أن تكون جميع هذه المجالات قابلة للتوجيه ومعروفة بواسطة خوادم DNS العامة.

   • لإثبات الملكية، يجب على مسؤول DNS إدخال سجل DNS النصي (TXT). سجل TXT هو نوع من سجلات الموارد في DNS المستخدمة لتوفير القدرة على ربط بعض النصوص العشوائية وغير المنسقة بمضيف أو اسم آخر.

   • يجب على مسؤول DNS إدخال سجل TXT هذا في المنطقة التي يجب إثبات ملكيتها. بعد هذه الخطوة، تقوم سحابة Webex بإجراء استعلام سجل TXT لهذا المجال.

   • في حالة نجاح استعلام TXT وتطابق النتيجة مع الرمز المميز الذي تم إنشاؤه من سحابة Webex، يتم التحقق من النطاق.

   • على سبيل المثال، يجب أن تثبت المسؤولة أنها تمتلك النطاق «example.com»، إذا كانت تريد أن تعمل Webex Hybrid Services على نطاقها.

   • من خلال https://admin.webex.com، تبدأ عملية التحقق من خلال إنشاء سجل TXT لمطابقة الرمز المميز الذي أنشأته سحابة Webex:

     

   • ثم يقوم مسؤول DNS بإنشاء سجل TXT لهذا المجال مع تعيين القيمة إلى 123456789abcdef123456789abcdef123456789abcdef 123456789abcdef 123456789abcdef، كما في المثال التالي:

     

   • في هذه المرحلة، يمكن للسحابة التحقق من أن سجل TXT للنطاق example.com يطابق الرمز المميز.

   • تقوم السحابة بإجراء بحث TXT DNS:

     

   • ونظرًا لأن قيمة TXT تتطابق مع قيمة الرمز المميز، فإن هذه المطابقة تثبت أن المسؤول أضاف سجل TXT لنطاقه الخاص إلى DNS العام، وأنها تمتلك النطاق.

2. التحقق من ملكية اسم DNS الخاص بـ Expressway-E.

   • يجب أن تتحقق السحابة من أن Expressway-E لديها هوية مؤكدة من إحدى سلطات الشهادات التي تثق بها السحابة. يجب أن يطلب مسؤول Expressway-E شهادة عامة لـ Expressway-E إلى إحدى سلطات التصديق هذه. لإصدار الشهادة، يقوم المرجع المصدق بإجراء عملية التحقق من الهوية، استنادًا إلى التحقق من صحة المجال (للشهادات التي تم التحقق من صحة المجال) أو التحقق من صحة المؤسسة (لشهادات المؤسسة التي تم التحقق من صحتها).

   • تعتمد المكالمات من وإلى السحابة على الشهادة التي تم إصدارها إلى Expressway-E. إذا كانت الشهادة غير صالحة، يتم إسقاط المكالمة.

يجب أن يتصل موصل جهاز Webex بـ Webex حتى تعمل المكالمات المختلطة.

يتم نشر Webex Device Connector في الشبكة الداخلية، والطريقة التي يتواصل بها مع السحابة هي من خلال اتصال HTTPS خارجي - وهو نفس النوع المستخدم لأي متصفح يتصل بخادم ويب.

يستخدم الاتصال بسحابة Webex TLS. موصل جهاز Webex هو عميل TLS، وسحابة Webex هي خادم TLS. على هذا النحو، يقوم Webex Device Connector بالتحقق من شهادة الخادم.

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

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

عند الاتصال بالأجهزة، تستخدم الأداة الشهادات الموثوقة التي تقدمها. الطريقة الحالية للقيام بذلك هي وضعها فيها [home folder]/.devicestool/certs.

قائمة شهادات المرجع المصدق مطلوبة أيضًا لـ Expressway-E في زوج العبور . يتواصل Expressway-E مع سحابة Webex باستخدام SIP مع TLS، ويتم فرضه عن طريق المصادقة المتبادلة. يثق Expressway-E في المكالمات الواردة من السحابة والقادمة إليها، فقط إذا كان CN أو SAN للشهادة المقدمة من السحابة أثناء إعداد اتصال TLS يطابق اسم الموضوع الذي تم تكوينه لمنطقة DNS على Expressway («callservice.webex.com»). لا تصدر الجهة المصدقة الشهادة إلا بعد التحقق من الهوية. يجب إثبات ملكية نطاق callservice.webex.com للحصول على شهادة موقعة. ونظرًا لأننا (Cisco) نمتلك هذا النطاق، فإن اسم DNS «callservice.webex.com» هو دليل مباشر على أن النظير البعيد هو Webex حقًا.

يقوم موصل التقويم بدمج Webex مع Microsoft Exchange 2013 أو 2016 أو 2019 أو Office 365 من خلال حساب انتحال الشخصية. يعمل دور إدارة انتحال شخصية التطبيق في Exchange على تمكين التطبيقات من انتحال شخصية المستخدمين في المؤسسة لأداء المهام نيابة عن المستخدم. يجب تكوين دور انتحال شخصية التطبيق في Exchange واستخدامه في موصل التقويم كجزء من تكوين Exchange على واجهة Expressway-C.

حساب انتحال شخصية Exchange هو الأسلوب الموصى به من Microsoft لهذه المهمة. لا يحتاج مسؤولو Expressway-C إلى معرفة كلمة المرور، لأنه يمكن إدخال القيمة في واجهة Expressway-C بواسطة مسؤول Exchange. لا تظهر كلمة المرور بوضوح، حتى إذا كان مسؤول Expressway-C لديه حق الوصول الجذري إلى مربع Expressway-C. يتم تخزين كلمة المرور مشفرة باستخدام نفس آلية تشفير بيانات الاعتماد مثل كلمات المرور الأخرى على Expressway-C.

لمزيد من الأمان، اتبع الخطوات الواردة في دليل النشر لخدمة التقويم Cisco Webex المختلط لتمكين TLS من أجل تأمين اتصالات EWS على السلك.

لمزيد من الأمان، اتبع الخطوات الواردة في نشر موصل تقويم Expressway Microsoft Exchange لتمكين TLS من أجل تأمين اتصالات EWS على السلك.