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

تعتبر هذه النقاط بالغة الأهمية إذا كنت ترغب في نشر ميزة الاتصال الهجين بنجاح لأجهزة 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 في مركز التحكم، وبالتالي سجل DNS SRV عام، على النحو التالي:

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

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

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

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

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

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

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

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

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

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

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

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

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

شركة لديها نطاق DNS مضبوط على "hacker.com" تشتري خدمات Webex الهجينة. شركة أخرى ، مع تعيين نطاقها الخاص إلى "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@example.com من تطبيق Webex الخاص بها. يجلس جون في مكتبه ويرى مكالمة على جهاز الفيديو الخاص به قادمة من jane.roe@example.com; هذا هو عنوان URI الخاص بالدليل المرتبط بحساب البريد الإلكتروني هذا.

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

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

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

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

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

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

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

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

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

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

   • من خلال 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 بالتحقق من شهادة الخادم.

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

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

عند التواصل مع الأجهزة، تستخدم الأداة شهادات موثوقة تقوم أنت بتوفيرها. الطريقة الحالية للقيام بذلك هي وضعها بين قوسين مربعين [home folder]/.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 الطريقة التي توصي بها مايكروسوفت لهذه المهمة. لا يحتاج مسؤولو Expressway-C إلى معرفة كلمة المرور، لأنه يمكن إدخال القيمة في واجهة Expressway-C بواسطة مسؤول Exchange. لا يتم عرض كلمة المرور بوضوح، حتى إذا كان لدى مسؤول Expressway-C حق الوصول الجذر إلى المربع Expressway-C . يتم تخزين كلمة المرور مشفرة باستخدام نفس آلية تشفير بيانات الاعتماد مثل كلمات المرور الأخرى على الطريق السريع-C.

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

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