اعتبارات نشر Zoom Node

تعرّف على المزيد حول كيفية دعم أمثلة النشر المختلفة لـ Zoom Node ووحدات خدمة Zoom Node

يتضمن هذا القسم عدة أمثلة على كيفية إمكانية أن يدعم Zoom Node وحدات الخدمة المختلفة مثل Zoom Meetings Hybrid و Zoom Phone Local Survivability (ZPLS). يمكن أن تبدو عمليات النشر النموذجية مع عنوان بروتوكول الإنترنت (IP) مخصص على النحو التالي من المخططات.

تتطلب كل خدمة يتم نشرها على Zoom Node عنوان بروتوكول الإنترنت (IP) فريدًا. سيُخصَّص لـ Zoom Node ما يصل إلى خمسة (5) عناوين بروتوكول الإنترنت (IP) إذا كان قد تم تخصيص عنوان محدد له للإدارة وعنوان واحد لكل خدمة يتم نشرها (حتى أربع) على Node. يمكن نشر Zoom Node الذي يشغّل خدمة واحدة فقط (مثل ZPLS) باستخدام عنوان بروتوكول الإنترنت (IP) واحد إذا تم تعيين Node والخدمة لمشاركة العنوان نفسه.

تُعرض أدناه عدة خيارات للنشر. لاحظ عدد عناوين بروتوكول الإنترنت (IP) والشهادات (CN/SANs) لخيارات النشر المختلفة.

الخيار 1: نشر Zoom Meetings Hybrid مع عناوين بروتوكول الإنترنت (IP) وأسماء مضيفين مخصصة

تلخّص الصورة أعلاه متطلبات تكوين عنوان بروتوكول الإنترنت (IP) والشهادة لنشر Zoom Meetings Hybrid في البيئات المحلية أو البيئات السحابية الهجينة.

يوضح الجدول أدناه مثال Node ويتضمن وحدات خدمة الوكيل النشط وMMR الخاصة به:

المكوّن	اسم المضيف	دور شهادة TLS	وظيفة
نظام تشغيل العقدة	node1.customer.com	الاسم الشائع (CN)	التنسيق الأساسي
وكيل Zoom الموصل	zcp1.customer.com	الاسم البديل للموضوع (SAN)	الإشارات والتحكم في الجلسة
الموجّه 1 لوحدة الوسائط	mmr1.customer.com	الاسم البديل للموضوع (SAN)	توجيه الوسائط ومعالجتها
الموجّه 2 لوحدة الوسائط	mmr2.customer.com	الاسم البديل للموضوع (SAN)	توجيه الوسائط ومعالجتها
الموجّه 3 لوحدة الوسائط	mmr3.customer.com	الاسم البديل للموضوع (SAN)	توجيه الوسائط ومعالجتها

يجب أن يعيّن لكل وحدة عنوان بروتوكول الإنترنت (IP) ثابتًا مخصصًا. إجمالي عناوين بروتوكول الإنترنت (IP) المطلوبة: خمسة (5)

توضح الصورة أعلاه الحد الأدنى من التكوين المطلوب للنشر Zoom Phone Local Survivability (ZPLS). تتيح ZPLS استمرار توفر خدمة الهاتف في حالة انقطاع الإنترنت أو السحابة عبر تشغيل منطق الاستمرارية محليًا على جهاز Zoom Node VM.

يجب تكوين أسماء المضيفين التالية في DNS وإدراجها في شهادة TLS:

• node1.customer.com

• zplsl.customer.com

تعيين وظائف اسم المضيف

المكوّن	اسم المضيف	دور شهادة TLS	وظيفة
نظام تشغيل العقدة	node1.customer.com	الاسم الشائع (CN)	التنسيق الأساسي
وحدة ZPLS	zplsl.customer.com	اسم بديل للموضوع	منطق الاستمرارية المحلية لـ Zoom Phone

تكوين شهادة TLS

الحقل	القيمة
الاسم الشائع (CN)	node1.customer.com
الأسماء البديلة للموضوع	zplsl.customer.com

يجب إنشاء الشهادات أو الحصول عليها (من جهة تصديق عامة أو خاصة) لتضمين كلٍّ من CN وSANs المذكورين أعلاه. يتيح ذلك التحقق الصحيح من TLS للاتصال الآمن بين الوحدات.

متطلبات عنوان بروتوكول الإنترنت (IP)

المقياس	القيمة / الوصف
إجمالي عناوين بروتوكول الإنترنت (IP) المطلوبة	5 (تخصيص عام)
مستخدم في سياق ZPLS	2 عناوين بروتوكول الإنترنت (IP) (1 لنظام التشغيل الخاص بالعقدة، 1 لوحدة ZPLS)

بينما تُطلب خمسة (5) عناوين بروتوكول الإنترنت (IP) للنشر العام، يتم استخدام عنواني IP فقط (2) بشكل نشط في نشر ZPLS: واحد لكل وحدة، يعمل على آلة افتراضية مخصصة لـ Node.

يسمح ZPLS بوحدة واحدة فقط لكل Node VM. لا يمكنك وضع ZPLS مع وحدات Zoom الأخرى على نفس VM.

كيف تقارن هذه المخططات؟ تُظهر الصورة الأولى مثالًا على نشر Zoom Meetings Hybrid. وتُظهر الصورة الثانية مثالًا على نشر Zoom Phone Local Survivability.

يمكنك مشاركة أول عنوان IP/اسم مضيف بين نظام التشغيل والوحدة الأولى، إذا رغبت، لتقليل عدد عناوين IP وأسماء المضيفين وأسماء الموضوع البديلة (SANs) المطلوبة.

الخيار 2: تم نشر اجتماعات زووم الهجينة باستخدام عنوان IP مشترك واسم مضيف مشترك

يكرر هذا التكوين بنية العقدة كما هو موضح في مخطط الاجتماعات الهجينة لـ Zoom في الخيار 1. ومع ذلك، في هذا النشر، فإن يشارك نظام التشغيل الخاص بالعقدة عنوان بروتوكول الإنترنت (IP) مع الوحدة المنشورة أولًا (عادةً ما يكون Zoom الموصل Proxy، ZCP). ويؤدي ذلك إلى تقليل استخدام عناوين IP مع الحفاظ على TLS والمتطلبات الوظيفية.

يجب تكوين أسماء المضيفين التالية في DNS وإدراجها في شهادة TLS:

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

تعيين وظائف اسم المضيف

المكوّن	اسم المضيف	دور شهادة TLS	وظيفة
ZCP (وكيل الموصل لـ Zoom)	zcp1.customer.com	الاسم الشائع (CN)	الإشارات والتحكم في الجلسة
الموجّه 1 لوحدة الوسائط	mmr1.customer.com	الاسم البديل للموضوع (SAN)	توجيه الوسائط ومعالجتها
الموجّه 2 لوحدة الوسائط	mmr2.customer.com	الاسم البديل للموضوع (SAN)	توجيه الوسائط ومعالجتها
الموجّه 3 لوحدة الوسائط	mmr3.customer.com	الاسم البديل للموضوع (SAN)	توجيه الوسائط ومعالجتها

تكوين شهادة TLS

الحقل	القيمة
الاسم الشائع (CN)	zcp1.customer.com
الأسماء البديلة للموضوع	mmr1.customer.com, mmr2.customer.com, mmr3.customer.com

يجب أن تتضمن الشهادات جميع أسماء SANs لدعم اتصال TLS الآمن بين عقدة Zoom والوحدات Zoom المثبتة.

متطلبات عنوان بروتوكول الإنترنت (IP)

المقياس	القيمة / الوصف
إجمالي عناوين بروتوكول الإنترنت (IP) المطلوبة	4
استراتيجية مشاركة عنوان بروتوكول الإنترنت (IP)	يشارك نظام التشغيل الخاص بالعقدة عنوان بروتوكول الإنترنت (IP) مع الوحدة الأولى (ZCP)
عناوين بروتوكول الإنترنت (IP) الفردية مطلوبة لـ	ZCP/MMR1، MMR2، MMR3

عندما يكون عنوان بروتوكول الإنترنت (IP) مشتركًا بين نظام التشغيل الخاص بالعقدة والوحدة الأولى المنشورة (ZCP)، فقط أربع (4) عناوين بروتوكول الإنترنت (IP) مطلوبة. يحقق هذا التصميم تحسينًا في استخدام عنوان بروتوكول الإنترنت (IP) مع الاستمرار في الامتثال لمعايير النشر.

تُظهر الصورة أعلاه عملية نشر ZPLS minimal حيث إن نظام التشغيل Node يشارك عنوان بروتوكول الإنترنت (IP) الخاص به مع وحدة ZPLS المثبتة. هذا هو السيناريو الوحيد في إطار عمل Zoom Node حيث تكون شهادة TLS لمضيف واحد صالحة.

يجب تكوين اسم المضيف التالي في DNS وإدراجه في شهادة TLS:

• zplsl.customer.com

تعيين وظائف اسم المضيف

المكوّن	اسم المضيف	دور شهادة TLS	وظيفة
وحدة ZPLS	zplsl.customer.com	الاسم الشائع (CN)	منطق الاستمرارية المحلية لـ Zoom Phone

تكوين شهادة TLS

الحقل	القيمة
الاسم الشائع (CN)	zcp1.customer.com
SANs	(غير مطلوب)

في هذا التكوين، تكفي شهادة لمضيف واحد لأن كلًا من نظام التشغيل ووحدة ZPLS يشتركان في نفس اسم المضيف وعنوان بروتوكول الإنترنت (IP).

متطلبات عنوان بروتوكول الإنترنت (IP)

المقياس	القيمة / الوصف
إجمالي عناوين بروتوكول الإنترنت (IP) المطلوبة	1
استراتيجية مشاركة عنوان بروتوكول الإنترنت (IP)	نظام التشغيل للعقدة وZPLS يشتركان في عنوان بروتوكول الإنترنت (IP) واحد
قيد النشر	يُسمح بوحدة واحدة فقط لكل جهاز VM للعقدة (ZPLS فقط)

ZPLS هو السيناريو الوحيد المدعوم في بنية Zoom Node حيث:

• شهادة لمضيف واحد (CN فقط) مقبولة

• يلزم عنوان بروتوكول الإنترنت (IP) واحد فقط للنشر بسبب مشاركة عنوان بروتوكول الإنترنت (IP) بين نظام التشغيل والوحدة

• لا يتم دعم وضع وحدات إضافية في نفس جهاز VM

حدِّد طريقة إدارة الشهادات التي تعمل بشكل أفضل لعمليات النشر لديك

تتطلب كل وحدة خدمة يتم نشرها على Zoom Node شهادة صالحة موقعة من جهة إصدار شهادات (CA) موثوقة علنًا من قائمة الثقة الخاصة بشهادات Zoom Node. ويشمل ذلك الجهات العامة المعروفة.

يقدّم Zoom Node طريقتين لإدارة الشهادات:

• Auto PKI‏: هذا الحل المبتكر يوفّر أتمتة لتسجيل الشهادات وتجديدها بأمان مع جهات إصدار الشهادات (CAs) الموثوقة علنًا. تتحمّل Zoom التكاليف المرتبطة بالتسجيل والتجديد.

• إحضار شهادتك الخاصة (BYOC)‏: مع هذا الخيار، تقوم بتوفير شهاداتك الخاصة، الموقعة من أي جهة إصدار شهادات (CA) رئيسية موثوقة علنًا. أنت تتولى تسجيل الشهادات وتجديدها. تنطبق اعتبارات إضافية بشأن إمكانية أن يدعم Zoom Node ما يصل إلى خمسة أسماء مضيفين/SANs عند استخدام شهادات يوفّرها العميل، وهي موضحة بمزيد من التفصيل أدناه.

إدارة الشهادات تلقائيًا باستخدام Auto PKI

يثبّت Zoom Auto PKI شهادات جهة إصدار الشهادات (CA) الصالحة والموثوقة علنًا تلقائيًا لمنصة Zoom Node، وكذلك لأي وحدات يتم نشرها عليها. كما تتم معالجة تجديد الشهادات تلقائيًا. وهذا يبسّط إدارة الشهادات لجميع الخدمات ولـ Zoom Node نفسه.

فهم تسجيل الشهادات وتجديدها باستخدام Auto PKI

يمكن أن يساعدك السيناريو التالي على فهم كيفية عمل تسجيل الشهادات وتجديدها.

على سبيل المثال: قام مسؤول بنشر مثيل Node جديد. يتطلب كل مثيل شهادة x509 صالحة. يجب ألا يغادر المفتاح الخاص للشهادة هذا المثيل مطلقًا.

تنفذ عملية Auto PKI الخطوات التالية:

1. استرجاع القالب: تسحب جميع قوالب التكوين المدعومة، بما في ذلك خيارات العديد من موفري CA، من خدمة Auto PKI في سحابة Zoom.

2. جمع عناوين بروتوكول الإنترنت (IP): تجمع جميع عناوين بروتوكول الإنترنت (IP) التي تستخدمها الخدمات التي تعمل على Node وترسلها إلى خدمة Auto PKI في سحابة Zoom.

3. توفير اسم DNS: تُرجع خدمة سحابة Auto PKI مجموعة من أسماء DNS بالتنسيق <instance_معرِّف>.<customer_معرِّف>.zoomonprem.com. يتم تكوين هذه النطاقات بسجلات A/AAAA.

4. طلب اسم DNS محجوز: يطلب اسم DNS محجوزًا بالتنسيق rsvd-<randomized_string>.<customer_معرِّف>.zoomonprem.com.

5. إنشاء طلب شهادة: ينشئ طلب شهادة x509، باستخدام أسماء DNS من الخطوة الثالثة في حقل SAN والاسم المحجوز من الخطوة الرابعة في حقل الاسم الشائع (CN).

6. إصدار الشهادة: يرسل طلب توقيع الشهادة (CSR) إلى خدمة Auto PKI في سحابة Zoom. ثم تعمل هذه الخدمة مع موردي CA لإصدار الشهادة، والتي تتضمن قائمة SAN وحقل CN من الخطوة السابقة.

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

يبسّط Auto PKI إدارة الشهادات على Zoom Node من خلال مراقبة تواريخ انتهاء الصلاحية تلقائيًا وطلب شهادات جديدة، مما يلغي الحاجة إلى التجديد اليدوي.

أحضر شهاداتك الخاصة (BYOC)

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

إذا اخترت استخدام شهاداتك الخاصة، فتذكّر أن الشهادة ستكون على خادم يتواصل مع عدة أسماء مضيفين. لذلك، يجب أن يدعم نوع الشهادة الذي تختاره تشفير حركة المرور الصادرة من أكثر من اسم مضيف واحد (CN للشهادة). يجب أن تكون جميع أسماء المضيفين المستخدمة لـ Node وأي خدمات منشورة قابلةً للحلّ علنًا بواسطة خدمات السحابة الخاصة بـ Zoom.

توصي Zoom بنوعين من الشهادات:

• شهادة Wildcard

• شهادة Multi-SAN (المعروفة أيضًا باسم شهادة Multi-Domain، أو شهادة SAN، أو شهادة UCC)

لن تعمل شهادة المضيف الواحد التقليدية مع Zoom Node، باستثناء الحالة المحددة التي تتم فيها مشاركة عنوان بروتوكول الإنترنت (IP) واحد واسم مضيف واحد بين Zoom Node ووحدة واحدة. لمزيد من السياق، راجع مخطط ZPLS في اعتبارات نشر Zoom Node القسم.

الشهادات ذات البدل: موصى بها للبساطة

يمكن للشهادة ذات البدل تشفير حركة المرور من أي اسم مضيف في النطاق. على سبيل المثال: يمكن لشهادة ذات بدل مثل *.customer.com أن تشفر حركة المرور من host1.customer.com و host2.customer.com أو أي اسم ضمن .customer.com.

عند نشر Zoom Node وتثبيت الشهادة ذات البدل، ستقوم تلقائيًا بتشفير حركة المرور لأي خدمات تنشرها على العقدة، بشرط أن تستخدم جميع الخدمات المنشورة اسم نطاق مؤهلاً بالكامل (FQDN) من نطاق البدل.

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

شهادات Multi-SAN أو متعددة النطاقات أو SAN أو UCC

يجب أن تعرف أسماء المضيفين وعناوين بروتوكول الإنترنت (IP) التي ستستخدمها للعقدة (حتى واحد [1]) وأي خدمات ستقوم بتثبيتها (حتى أربع [4]).

هذه المعلومات مطلوبة قبل تسجيل شهادة.

تُعد شهادة Multi-SAN ضرورية لـ Zoom Node لأنها تُشفّر حركة المرور من خمسة (5) أسماء مضيفين. يتطلب طلب هذه الشهادة لمرة واحدة معرفة مسبقة بجميع المعلومات اللازمة، بما في ذلك أسماء العقد المخطط لها وأسماء جميع الخدمات المقرر نشرها على العقدة. على سبيل المثال، مع وحدة مثل ZPLS، لا يتم نشر سوى وحدة ZPLS واحدة لكل عقدة، لذا لا يلزم سوى SAN إضافي واحد لاسم مضيف خدمة ZPLS.

يمكن استخدام الجدول التالي كمثال:

اسم المضيف (SAN)	عنوان بروتوكول الإنترنت (IP)
zoom-node01.company.com	10.1.50.100
zpls.company.com	10.1.50.100
zoom-recording.company.com	10.1.50.101
zoom-ندوة عبر الإنترنت.company.com	10.1.50.102
(الخدمة 4 - غير مستخدمة في هذا المثال)	(غير متاح)

هذا المثال هو لتكوين نموذجي، مع استضافة عقدة واحدة لـ ZPLS على نفس عنوان IP بالإضافة إلى خدمتين إضافيتين على عناوين IP منفصلة. استبدل "company.com" بنطاقك الفعلي واستخدم عناوين IP الخاصة بشبكتك.

متطلبات حلّ DNS

يتطلب Zoom أن تكون أسماء المضيفين قابلة للحل علنًا حتى يمكن إنشاء ثقة ثنائية الاتجاه. يجب تضمين جميع أسماء مضيفي Zoom Node وجميع أسماء مضيفي الخدمات المنشورة على Nodes ضمن منطقة DNS.

إذا كانت مؤسستك تشغّل خدمات أو نطاقات DNS داخلية وخارجية منفصلة، فيجب استضافة أسماء مضيفي Zoom Node في منطقة يمكن حلّها بواسطة خوادم DNS الخارجية لديك (ويمكن تقييدها بحيث لا تُحل إلا لنطاقات IP الخاصة بـ Zoom). يجب أن يتواصل مستخدمو Zoom الداخليّون و سحابة Zoom باستخدام المجموعة نفسها من أسماء المضيفين.