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

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

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

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

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

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

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

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

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

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

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

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

مثال

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

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

موقع خدمة _sips._tcp.example.com SRV:

الأولوية = 10

الوزن = 10

المنفذ = 5062

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

موقع خدمة _sips._tcp.example.com SRV:

الأولوية = 10

الوزن = 10

المنفذ = 5062

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

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

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

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

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

تظهر مصافحة TLS في الرسم البياني التالي:

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

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

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

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

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

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

 والبروتوكول: _sips._tcp.mtls.example.com الأولوية: 1 الوزن: 10 رقم المنفذ: الهدف 5062: us-expe1.example.com 

الوصول من شركة إلى شركة، والوصول عبر الأجهزة المحمولة وعن بُعد، وحركة مرور Webex على نفس زوج Expressway

تستخدم مكالمات Business-to-Business (B2B) والوصول من الأجهزة المحمولة وعن بُعد (MRA) المنفذ 5061 لـ SIP TLS، وتستخدم حركة مرور Webex المنفذ 5062 لـ SIP TLS مع مصادقة متبادلة.

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

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

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

   • مجال البريد الإلكتروني

   • مجال DNS للطريق السريع-E

   • نطاق URI للدليل

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

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

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

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

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

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

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

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

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

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

لضمان هذه الملكية، يلزم اتباع خطوتي إثبات ملكية النطاق:

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 لهذا المجال بالقيمة التي تم تعيينها على 123456789abcdef123456789abcdef123456789abcdef123456789abcdef، كما في المثال التالي:

     

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

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

     

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

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

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

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

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

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

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

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

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

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

مطلوب أيضا قائمة بشهادات المرجع المصدق للطريق السريع-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 . يتم تخزين كلمة المرور مشفرة باستخدام نفس آلية تشفير بيانات الاعتماد مثل كلمات المرور الأخرى على الطريق السريع-C.

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

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