يسمح نشر زوج Expressway-C و Expressway-E بإجراء المكالمات من وإلى الإنترنت باستخدام تقنياتاجتياز جدار الحماية. هذا النشر هو ما يأخذ التحكم في المكالمات المحلية بشكل آمن ويربطه ب Cisco 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. موقع خدمة SRV example.com:

الأولوية = 10

الوزن = 10

المنفذ = 5062

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

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

الأولوية = 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 وسحابة Cisco Webex . يسمى هذا المفهوم TLS مع المصادقة المتبادلة وهو مطلوب عند التكامل مع Cisco Webex.

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

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

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

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

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

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

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

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

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

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

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

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

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

قصة لإظهار أهمية التحقق من ملكية النطاق

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

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

شركة لديها نطاق DNS مضبوط على "hacker.com" تشتري Cisco 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 في هذا المثال.

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

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

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

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

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

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

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

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

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

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

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

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

     

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

     

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

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

     

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

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

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

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

يجب تسجيل مضيف موصل Expressway-C في Cisco Webex حتى تعمل الخدمات المختلطة.

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

يستخدم التسجيل والاتصال بسحابة Cisco Webex طبقة النقل الآمنة (TLS). Expressway-C هو عميل TLS ، وسحابة Cisco Webex هي خادم TLS. على هذا النحو ، يتحقق Expressway-C من شهادة الخادم.

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

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

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

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

إذا سمحت بالتثبيت التلقائي لشهادات المرجع المصدق، إعادة توجيهك إلى https://admin.webex.com (مدخل الإدارة). تتم إعادة التوجيه بواسطة الطريق السريع-C نفسه دون أي تدخل من المستخدم. يجب عليك، بصفتك مسؤول Cisco Webex ، المصادقة من خلال اتصال HTTPS. بعد فترة وجيزة ، تدفع السحابة شهادات CA إلى الطريق السريع-C.

حتى يتم تحميل الشهادات إلى مخزن الثقة Expressway-C، لا يمكن إنشاء اتصال HTTPS.

لتجنب هذه المشكلة، يتم تثبيت Expressway-C مسبقا مع شهادات CA الموثوق بها من Cisco Webex. يتم استخدام هذه الشهادات فقط لإعداد اتصال HTTPS الأولي والتحقق من صحته، ولا تظهر في قائمة الثقة Expressway-C. بمجرد سحب شهادات المراجع المصدقة الموثوق بها من السحابة من خلال اتصال HTTPS الأولي هذا، تتوفر هذه الشهادات للاستخدام على مستوى النظام الأساسي؛ ثم تظهر في قائمة الثقة Expressway-C.

تعرض هذه القائمة شهادات المرجع المصدق التي تستخدمها سحابة Cisco Webex حاليا. قد تتغير هذه القائمة في المستقبل:

• C = IE ، O = بالتيمور ، OU = CyberTrust ، CN = Baltimore CyberTrust Root

• C = الولايات المتحدة ، O = GTE Corporation ، OU = GTE CyberTrust Solutions ، Inc. ، CN = GTE CyberTrust Global Root

• C = الولايات المتحدة ، O = The Go Daddy Group، Inc. ، OU = Go Daddy Class 2 المرجع المصدق

• C = الولايات المتحدة ، ST = أريزونا ، L = سكوتسديل ، O = GoDaddy .com ، Inc. ، CN = Go Daddy Root Certificate Authority - G2

• C = BM ، O = QuoVadis Limited ، CN = Quovadis Root CA 2

• C = US ، O = thawte ، Inc. ، OU = قسم خدمات التصديق ، OU = (c) 2006 thawte، Inc. - للاستخدام المصرح به فقط ، CN = thawte Primary Root CA

• C = الولايات المتحدة ، O = VeriSign، Inc. ، OU = الفئة 3 سلطة التصديق الابتدائية العامة

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

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

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

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