تكوين مرونة XMPP

المقدمة

يصف هذا المستند كيفية إعداد مرونة بروتوكول التواجد والمراسلة القابلة للتوسع (XMPP) على خادم الاجتماعات (CMS) من Cisco.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• يجب إعداد تجميع قاعدة البيانات قبل مرونة XMPP. هذا هو الارتباط الخاص بإعداد "مجموعات قواعد البيانات"

https://www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/210530-Configure-Cisco-Meeting-Server-Call-Brid.html

• يجب تكوين مكون CallBridge على CMS
• توصي Cisco بأن يكون لديك 3 عقد XMPP على الأقل لتتمكن من إعداد مرونة XMPP
• عندما يكون الإعداد في وضع المرونة، يتم تحميل خوادم XMPP ضمن عملية نشر بنفس التكوين
• فهم الشهادات الموقعة ذاتيا، والتوقيع من قبل المرجع المصدق
• خادم اسم المجال (DNS) مطلوب
• يتطلب من هيئة شهادة محلية أو هيئة شهادة عامة إنشاء شهادات 

ملاحظة: لا يوصى باستخدام شهادات موقعة ذاتيا لبيئة الإنتاج

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

• CMS
• برنامج المحاكاة الطرفية PuTTY Secure Shell (SSH) لمعالج إدارة اللوحة الرئيسية (MMP)
• مستعرض ويب مثل Firefox و Chrome

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.

التكوين

 الرسم التخطيطي للشبكة

تظهر هذه الصورة تبادل رسائل XMPP وحركة مرور التوجيه.

التكوين

يستخدم هذا المثال لنشر مرونة XMPP ثلاثة خوادم XMPP، ويقوم بتكوينه لأول مرة.

ملاحظة: إذا تم نشر مرونة XMPP مسبقا، فمن المستحسن إعادة ضبط جميع الخوادم.

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

الخطوة 1. إنشاء شهادات لمكون XMPP.

قم بإنشاء CSR ثم أنت هذا الأمر لإنشاء شهادة مطابقة من خلال هيئة الترخيص المحلية/ سلطة التصديق العامة كما هو مطلوب

PKI <key/cert basename> 

الخطوة 2. أستخدم CSR المذكور أعلاه وقم بإنشاء شهادة باستخدام المرجع المصدق المحلي. يمكنك إستخدام دليل شهادة VCS لإنشاء شهادات باستخدام مرجع ترخيص Microsoft، الملحق 5 الصفحة 32

https://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-8/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-8.pdf

قم بتحميل الشهادة على العقد الثلاث جميعها باستخدام خادم WINSCP/SFTP. للتحقق مما إذا كانت الشهادات التي يتم تحميلها تستخدم أمرا على MMP/SSH

الأمر: قائمة PKI

ملاحظة: في المختبرات، يتم إستخدام شهادة واحدة لجميع عقد XMPP الثلاث.

الخطوة 3. قم بتكوين CMS لاستخدام مكون XMPP.

cb1> xmpp domain tptac9.com
cb1>xmpp listen a
cb1>xmpp certs abhiall.key abhiall.cer certall.cer
 
*certall.cer= CA certificate

تلميح: إذا كان المرجع المصدق يوفر حزمة شهادة ثم قم بتضمين الحزمة كملف منفصل إلى الشهادة. حزمة الشهادة هي ملف واحد (بامتداد .pem، .cer أو.crt) يحتوي على نسخة من شهادة CA الجذر وجميع الشهادات الوسيطة في السلسلة. يجب أن تكون الشهادات متتالية مع وجود شهادة المرجع المصدق الجذر كالأخيرة في حزمة الشهادة. يتطلب العملاء الخارجيون (على سبيل المثال مستعرضات الويب وعملاء XMPP) تقديم حزمة الشهادة والشهادة من قبل خادم XMPP على التوالي، عند إعداد اتصال آمن.

 عندما تكون حزمة الشهادات مطلوبة. الأمر المذكور أعلاه سيكون

cb1> xmpp certs abhiall.key abhiall.cer certallbundle.cer
 
certallbundle.cer= CA certificate + Intermediate CA + Intermediate CA1 + Intermediate CA2 +.... + Intermediate CAn +  Root CA
 
where n is an integer

عند إستخدام 3 شهادات ل 3 عقد XMPP خاصة. يرجى التأكد من تجميع الشهادات

xmppserver1.crt + xmppserver2.crt + xmppserver3.crt= xmpp-cluster-bundle.crt

يتم إستخدام شهادة واحدة abhiall.cer في المستند.

يرجى الرجوع إلى هذا الدليل لمعرفة المزيد من التفاصيل حول الشهادات

https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-2/Certificate-Guidelines-Scalable-and-Resilient-Deployments-2-2.pdf

الخطوة 4. قم بتحميل الشهادات من خلال SFTP إلى جميع CMS، والتي تشغل مكون XMPP.

cb1>> xmpp cluster trust xmpp-cluster-bundle.crt

في المختبر XMPP Cluster Trust abhiall.cer

cb1>أمان مجموعات xmpp|all.cer

الخطوة 5. إضافة جسور المكالمات إلى خادم XMPP.

cb1> xmpp callBridge يضيف cb1

يتم إنشاء سر، وهذا يقوم بتكوين خادم XMPP للسماح بالاتصالات مع Call Bridge المسمى cb1.

ملاحظة: يتم إنشاء المجال واسم جسر الاتصال والسر، وستحتاج إلى هذه المعلومات لاحقا عند تكوين وصول جسر الاتصال إلى خادم XMPP (حتى يقدم جسر الاتصال تفاصيل المصادقة إلى خادم XMPP)

يتم إستخدام الأمر أعلاه لإضافة جسور اتصال أخرى إلى عقدة xmpp نفسها.

cb1> xmpp callBridge يضيف cb2

cb1> xmpp callBridge يضيف cb3

ملاحظة:يجب أن يكون لكل جسر مكالمة اسم فريد. إذا لم تكن قد انتهيت بالفعل من ملاحظة تفاصيل "جسور الاتصال" التي قمت بإضافتها إلى خادم XMPP، فاستخدم الأمر: xmpp callBridge list

cb1> xmpp disable

يؤدي هذا إلى تعطيل عقدة خادم XMPP

الخطوة 6. تمكين مجموعة XMPP.

تمكين قطاع CB1> xmpp

تهيئة مجموعة XMPP على هذه العقدة. يقوم هذا الأمر بإنشاء نظام مجموعة xmpp بعقدة واحدة، ويتم انضمام العقد الأخرى (خوادم xmpp) إلى نظام المجموعة هذا.

تهيئة نظام المجموعة CB1> XMPP

إعادة تمكين هذه العقدة

cb1>xmpp enable

الخطوة 7. قم بإضافة "جسور المكالمات" إلى عقدة XMPP الثانية وانضم إليها في نظام مجموعة.

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

cb2> xmpp callBridge add-secret cb1

إدخال اتصال سر الجسر

للتحقق من السرية، الرجاء تشغيل قائمة إستدعاء XMPP لجسر الأمر. وهو يسرد كل السر الذي تم إنشاؤه على العقدة الأولى.

بعد إضافة كافة "جسور الاتصال" السرية إلى العقدة الثانية.

cb2>> xmpp disable
cb2>> xmpp cluster enable
cb2>> xmpp enable
cb2>> xmpp cluster join <cluster>

نظام المجموعة: هو عنوان IP أو اسم المجال للعقدة الأولى

الخطوة 8. قم بإضافة "جسور المكالمات" إلى عقدة XMPP الثالثة والانضمام إليها في نظام مجموعة.

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

cb3>> xmpp callBridge add-secret cb1

إدخال اتصال سر الجسر

الآن للتحقق من السر. يمكنك تشغيل قائمة الأمر xmpp callBridge. الأمر قائمة كل السر الذي تم إنشاؤه على العقدة الأولى

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

cb3>> xmpp disable
cb3>> xmpp cluster enable
cb3>> xmpp enable
cb3>> xmpp cluster join <cluster>

نظام المجموعة: هو عنوان IP أو اسم المجال للعقدة الأولى

الخطوة 9. قم بتكوين كل Call Bridge باستخدام تفاصيل المصادقة الخاصة بخوادم XMPP في نظام المجموعة. وهذا يمكن جسور الاتصال من الوصول إلى خوادم XMPP.

انتقل إلى WebAdmin > التكوين > عام وأدخل ما يلي:

1. أضف اسم "جسر المكالمات" الفريد، ولا يتطلب أي جزء مجال.
2. أدخل مجال مجال مجال خادم XMPP tptac9.com
3. عنوان خادم XMPP. قم بتعيين هذا الحقل إذا كنت ترغب في أن يستخدم هذا Call Bridge خادم XMPP في موقع واحد فقط، أو لم يتم تكوين DNS لديك. يقلل إستخدام خادم XMPP في موقع واحد من زمن الوصول.
4. ترك هذا الحقل فارغا للسماح ل Call Bridge بتجاوز الفشل بين خوادم XMPP، يتطلب ذلك إعداد إدخالات DNS. 

إذا كنت تخطط لاستخدام خادم اسم المجال (DNS) للاتصال بين "جسور الاتصال" وخوادم XMPP، فأنت بحاجة أيضا إلى إعداد سجل DNS SRV لمجموعة XMPP لحل سجل لكل من خوادم XMPP في المجموعة إلى DNS A. تنسيق سجل DNS SRV هو: _xmpp-component._tcp.

_xmpp-component._tcp.example.com. 86400 IN SRV 0 0 5222 xmppserver1.example.com,  _xmpp-component._tcp.example.com. 86400 IN SRV 0 0 5223 xmppserver2.example.com, _xmpp-component._tcp.example.com. 86400 IN SRV 0 0 5223 xmppserver3.example.com. 

يحدد المثال أعلاه المنفذ 5223 (أستخدم منفذا آخر إذا كان 5223 مستخدما بالفعل).

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

سر CB1 هو

CallBridge: cb1

المجال: tptac9.com

سري: KVGp1SRzWVabhiPVAb1

بالمثل ل CB2 و CB3، كرر هذه الخطوات لجميع جسور المكالمات الثلاثة CB1 و CB2 و CB3.

بعد إجراء هذه الخطوات، الرجاء التحقق من حالة نظام المجموعة في كافة جسور الاتصال الثلاثة

التحقق من الصحة

قم بتشغيل حالة نظام المجموعة cb1> xmpp، وهذا الأمر للحصول على تقرير حول حالة البث المباشر لنظام المجموعة xmpp. في حالة فشل نظام المجموعة، يقوم هذا الأمر بإرجاع إحصائيات خادم XMPP، الذي يتم تشغيله على خادم الاجتماعات هذا فقط. أستخدم هذا الأمر لمحاولة تشخيص مشاكل الاتصال والمساعدة في تشخيصها.

تظهر هذه الصورة العقد، الأولى كقائد 10.106.81.30 والثانية كتابع.

وبالمثل، تحقق من حالة باقي العقدتين.

على العقدة الثانية

في العقدة الثالثة

استكشاف الأخطاء وإصلاحها

تم إعداد مرونة XMPP بنجاح. قد تكون هناك مشاكل قد تظهر عند إستخدام مرونة XMPP.

السيناريو 1. تم التحقق من تكوين DNS، تشير الأخطاء الموجودة في لقطات الشاشة إلى مشاكل DNS.

إذا تم رؤية هذه الأخطاء، فتحقق من التكوين لسجلات SRV.

في مرونة XMPP، يتم التحكم في خادم XMPP الذي يتصل به جسر الاتصال عبر DNS. يستند هذا الخيار إلى أولوية DNS ووزنها المعطى. يتصل "جسر المكالمات" بخادم XMPP واحد فقط في كل مرة. لا يوجد حاجة إلى اتصال كافة "جسور المكالمات" بخادم XMPP نفسه نظرا لإعادة توجيه جميع حركات مرور البيانات إلى الخادم الرئيسي. إذا نتج عن مشكلة في الشبكة فقدان الاتصال بخادم XMPP في Call Bridge، يحاول Call Bridge إعادة الاتصال بخادم XMPP آخر. يجب تكوين "جسر المكالمات" إلى أي خادم XMPP يمكن الاتصال به.

لتمكين إتصالات العميل، إستخدام عميل WebRTC، يلزم إستخدام سجل _xmpp-client._tcp. في عملية نشر نموذجية، يتم الحل إلى المنفذ 522. في الداخل، الشبكة المحلية (LAN)، إذا كان الخادم الرئيسي قابلا للتوجيه مباشرة، فيمكنه الحل إلى خدمة XMPP، التي تعمل على الخادم الرئيسي.

على سبيل المثال: يمكن أن يحتوي _xmpp-client._tcp.tptac9.com على سجلات SRV التالية:

_xmpp-client._tcp. tptac9.com 86400 في SRV 10 50 5222 cb1. tptac9.com

نصائح حول إعداد سجلات DNS لعقد خادم XMPP. من أجل، مرونة XMPP، تحتاج إلى DNS للاتصال بين Call Bridges وخوادم XMPP، ستحتاج أيضا إلى إعداد سجل DNS SRV لمجموعة XMPP لحل سجل لكل من خوادم XMPP في المجموعة إلى DNS A. تنسيق سجل DNS SRV هو: _xmpp-component._tcp.tptac9.com

وفقا للإعداد الذي تمت مناقشته ل 3 خوادم XMPP، يتم عرض السجل الذي يحل جميع الخوادم الثلاثة

_xmpp-component._tcp.tptac9.com. 86400 في SRV 0 0 5223 cb1.tptac9.com

_xmpp-component._tcp.tptac9.com. 86400 في SRV 0 0 5223 cb2.tptac9.com

_xmpp-component._tcp.tptac9.com. 86400 في SRV 0 0 5223 cb3.tptac9.com

يعين المثالالميناء 5223، أي آخر ميناء يستطيع أيضا كنت استعملت إن 5223 يكون بالفعل استعملت. مهما، ضمنت ال يستعمل ميناء ينبغي كنت فتحت.

السيناريو 2. عندما تظهر صفحة حالة CMS فشل المصادقة.

غالبا ما يظهر فشل المصادقة عندما لا يتم إدخال السر المشترك أو إدخاله بشكل غير صحيح. الرجاء التأكد من إدخال "السر المشترك"، في حالة نسيانه وليس مفيدا. الرجاء إدخال SSH إلى الخادم وتشغيل هذا الأمر: قائمة إستدعاء XMPP

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

السيناريو 3. في حالة نظام المجموعة XMPP إدخالات مكررة لعقد XMPP.

يوضح هذا الإخراج الإدخال المكرر للعقدة 10.61.7.91:5222

cb1> xmpp cluster status
State: LEADER
List of peers
10.61.7.91:5222
 
10.61.7.91:5222
10.59.103.71:5222
10.59.103.70:5222 (Leader)
 

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

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

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi67717

يرجى مراجعة الصفحة 94 من الدليل أدناه 

https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-3/Cisco-Meeting-Server-2-3-Scalable-and-Resilient-Deployments.pdf