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

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

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

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

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

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

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

يفصل الجدول أدناه العقدة النموذجية ويتضمن وكيلها النشط ووحدات خدمة 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 (ZPLS). تُمكّن ZPLS استمرار توفر خدمة الهاتف في فعالية حدوث انقطاع الإنترنت أو السحابة عبر تشغيل منطق الاستمرارية محليًا على آلة افتراضية لـ Zoom Node.

يجب تهيئة أسماء المضيفين التالية في 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	عنوانا بروتوكول الإنترنت (IP) 2 (1 لنظام تشغيل العقدة، و1 لوحدة ZPLS)

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

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

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

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

الخيار 2: نشر Zoom Meetings Hybrid مع عنوان IP مشترك واسم مضيف مشترك

يعيد هذا التكوين بنية Node كما تظهر في مخطط Zoom Meetings Hybrid للخيار 1. ومع ذلك، في هذا النشر، فإن نظام تشغيل Node يشارك عنوان بروتوكول الإنترنت (IP) الخاص به مع الوحدة المنشورة الأولى (عادةً وكيل Zoom للموصل، 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 Node والوحدات Zoom المثبتة.

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

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

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

تُظهر الصورة أعلاه نشرًا أدنى لـ ZPLS حيث إن نظام تشغيل 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)	نظام تشغيل Node وZPLS يشتركان في عنوان بروتوكول الإنترنت (IP) واحد
قيد النشر	يُسمح بوحدة واحدة فقط لكل آلة افتراضية Node (ZPLS فقط)

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

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

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

• لا يُدعَم وضع وحدات إضافية في نفس الآلة الافتراضية

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

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

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

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

• إحضار شهادتك الخاصة (BYOC): مع هذا الخيار، توفر شهاداتك الخاصة الموقعة من أي جهة إصدار شهادات رئيسية موثوقة علنًا. أنت تتولى تسجيل الشهادات وتجديدها. تنطبق اعتبارات إضافية بشأن إمكانية دعم 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 بنوعين من الشهادات:

• شهادة حرف بدل

• شهادة متعددة SAN (تُعرف أيضًا باسم شهادة متعددة المجالات، أو شهادة SAN، أو شهادة UCC)

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

شهادات حرف البدل: موصى بها للبساطة

يمكن لشهادة حرف البدل تشفير حركة البيانات من أي اسم مضيف في المجال. على سبيل المثال: يمكن لشهادة حرف بدل مثل *.customer.com تشفير حركة البيانات من مضيف1.customer.com و مضيف2.customer.com أو أي اسم ضمن .customer.com.

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

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

شهادات متعددة SAN، أو متعددة المجالات، أو SAN، أو UCC

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

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

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

هذا المثال لتكوين نموذجي، حيث يستضيف Node واحد ZPLS على عنوان IP نفسه بالإضافة إلى خدمتين إضافيتين على عناوين IP منفصلة. استبدل “company.com” بمجالك الفعلي واستخدم عناوين بروتوكول الإنترنت (IP) الخاصة بشبكتك.

متطلبات تحليل DNS

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

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