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

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

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

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

### <mark style="color:أزرق;">الخيار 1: نشر Zoom Meetings Hybrid بعناوين IP وأسماء مضيفين مخصصة</mark>

<figure><img src="https://3637835738-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-184792dfe5a78f13dbe0a8f67651f064fe826f21%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

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

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

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

{% hint style="info" %}
يجب عليك تخصيص عنوان IP ثابت مخصص لكل وحدة. إجمالي عناوين IP المطلوبة: خمسة (5)
{% endhint %}

<figure><img src="https://3637835738-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-2edb7c64b83b0edaaf03d291a85d819051a8da00%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

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

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

* `node1.customer.com`
* `zplsl.customer.com`

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

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

**تكوين شهادة TLS**

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

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

**متطلبات عنوان IP**

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

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

{% hint style="warning" %}
يسمح ZPLS بوحدة واحدة فقط لكل جهاز افتراضي Node. لا يمكنك مشاركة ZPLS مع وحدات Zoom أخرى على نفس الجهاز الافتراضي.
{% endhint %}

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

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

### <mark style="color:أزرق;">الخيار 2: نشر Zoom Meetings Hybrid بعنوان IP ومضيف مشتركين</mark>

<figure><img src="https://3637835738-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-6b1181f4394323c6364dc3dde2d10299e0000f9c%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

يعيد هذا التكوين هيكل الـ 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 والوحدات المنشورة المثبتة.

**متطلبات عنوان IP**

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

{% hint style="info" %}
عندما يتم **مشاركة** عنوان IP بين نظام تشغيل الـ Node والوحدة المنشورة الأولى (ZCP)، فقط **أربع (4) عناوين IP** مطلوبة. يهدف هذا التصميم إلى تحسين استخدام عناوين IP مع الاستمرار في الامتثال لمعايير النشر.
{% endhint %}

<figure><img src="https://3637835738-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-043999f43a7b7f32d98af79cee7e29ca0d9b526e%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

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

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

* `zplsl.customer.com`

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

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

**تكوين شهادة TLS**

| الحقل                          | القيمة              |
| ------------------------------ | ------------------- |
| الاسم الشائع (CN)              | `zcp1.customer.com` |
| الأسماء البديلة للموضوع (SANs) | (غير مطلوب)         |

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

**متطلبات عنوان IP**

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

{% hint style="warning" %}
ZPLS هو السيناريو الوحيد المدعوم في بنية Zoom Node حيث:

* شهادة لمضيف واحد (CN فقط) مقبولة
* مطلوب عنوان IP واحد فقط للنشر بسبب مشاركة عنوان IP بين نظام التشغيل والوحدة
* لا يتم دعم إيواء وحدات إضافية على نفس الجهاز الافتراضي
  {% endhint %}

### <mark style="color:أزرق;">قرر طريقة إدارة الشهادات التي تناسب عمليات النشر لديك</mark>

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

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

* **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_identifier>.<customer_identifier>.zoomonprem.com`. يتم تكوين هذه النطاقات بسجلات A/AAAA.
4. **طلب اسم DNS محجوز**: يطلب اسم DNS محجوز بالتنسيق `rsvd-<randomized_string>.<customer_identifier>.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 الشهادة). يجب أن تكون جميع أسماء المضيف المستخدمة للنظام والوحدات المنشورة قابلة للحل علنًا بواسطة خدمات سحابة Zoom.

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

* **شهادة wildcard (شاملة)**
* **شهادة متعددة SAN** (المعروفة أيضًا باسم شهادة متعددة النطاقات، شهادة SAN، أو شهادة UCC)

{% hint style="danger" %}
لن تعمل شهادة المضيف المفرد النموذجية مع Zoom Node، باستثناء السيناريو المحدد حيث يتم مشاركة عنوان IP واحد واسم مضيف واحد بين Zoom Node ووحدة واحدة. لرؤية سياق إضافي، راجع مخطط ZPLS في [#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname](#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname "mention") القسم.
{% endhint %}

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

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

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

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

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

{% hint style="warning" %}
يجب أن تعرف أسماء المضيفين وعناوين IP التي ستستخدمها للـ Node (حتى واحد \[1]) وأي خدمات ستقوم بتثبيتها (حتى أربعة \[4]).

**هذه المعلومات مطلوبة قبل تسجيل الشهادة**.
{% endhint %}

شهادة متعددة-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-webinar.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 باستخدام نفس مجموعة أسماء المضيف.