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

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

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

يوضح الجدول أدناه تفاصيل العقدة النموذجية ويتضمن وحدات خدمة الوكيل النشط و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) | توجيه الوسائط ومعالجتها  |

{% 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)**&#x200F;. يتيح ZPLS استمرار توفر خدمة الهاتف في حالة حدوث انقطاع في الإنترنت أو سحابة من خلال تشغيل منطق الاستمرارية محليًا على جهاز Zoom Node VM.

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

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

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

| المكوّن             | اسم المضيف           | دور شهادة TLS        | الوظيفة                             |
| ------------------- | -------------------- | -------------------- | ----------------------------------- |
| نظام التشغيل للعقدة | `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    | عنوانا IP (2) (واحد لنظام التشغيل للعقدة، وواحد لوحدة ZPLS) |

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

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

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

يمكنك مشاركة أول عنوان بروتوكول الإنترنت (IP)/اسم المضيف بين نظام التشغيل والوحدة الأولى، إذا رغبت، لتقليل عدد عناوين بروتوكول الإنترنت (IP) وأسماء المضيفين وأسماء SAN البديلة (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 الموصل Proxy، ZCP). يؤدي ذلك إلى تقليل استخدام عنوان بروتوكول الإنترنت (IP) مع الحفاظ على TLS والمتطلبات الوظيفية.

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

* `zcp1.customer.com`
* `mmr1.customer.com`
* `mmr2.customer.com`
* `mmr3.customer.com`

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

| المكوّن                 | اسم المضيف          | دور شهادة TLS              | الوظيفة                  |
| ----------------------- | ------------------- | -------------------------- | ------------------------ |
| ZCP (Zoom الموصل Proxy) | `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                                                          |

{% hint style="info" %}
عندما يكون عنوان بروتوكول الإنترنت (IP) **مشتركًا** بين نظام التشغيل للعقدة والوحدة الأولى المنشورة (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 حيث إن **نظام التشغيل للعقدة يتشارك عنوان بروتوكول الإنترنت (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) | يشارك نظام التشغيل للعقدة وZPLS عنوان بروتوكول الإنترنت (IP) واحدًا |
| قيد النشر                                      | يُسمح بوحدة واحدة فقط لكل جهاز VM للعقدة (ZPLS فقط)                 |

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

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

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

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

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

* **Auto PKI**‎: هذا الحل المبتكر يؤتمت تسجيل الشهادات الآمنة وتجديدها مع سلطات إصدار الشهادات الموثوقة علنًا (CAs). تتحمل Zoom التكاليف المرتبطة بالتسجيل والتجديد.
* **Bring Your Own Certificate (BYOC)**&#x200E;: مع هذا الخيار، توفر شهاداتك الخاصة، الموقعة من أي سلطة إصدار شهادات رئيسية موثوقة علنًا. أنت تتولى تسجيل الشهادات وتجديدها. تنطبق اعتبارات إضافية فيما يتعلق بإمكانية 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 التي تستخدمها الخدمات التي تعمل على العقدة وترسلها إلى خدمة Auto PKI في سحابة Zoom.
3. **توفير اسم DNS**: تُرجع خدمة Auto PKI السحابية مجموعة من أسماء DNS بالتنسيق `<معرِّف_المثيل>.<معرِّف_العميل>.zoomonprem.com`. يتم تكوين هذه النطاقات بسجلات A/AAAA.
4. **طلب اسم DNS محجوز**: يطلب اسم DNS محجوزًا بالتنسيق `rsvd-<سلسلة_عشوائية>.<معرِّف_العميل>.zoomonprem.com`.
5. **إنشاء طلب شهادة**: يُنشئ طلب شهادة x509، باستخدام أسماء DNS من الخطوة الثالثة في حقل SAN والاسم المحجوز من الخطوة الرابعة في حقل الاسم الشائع (CN).
6. **إصدار الشهادة**: يرسل طلب توقيع الشهادة (CSR) إلى خدمة Auto PKI في سحابة Zoom. ثم تعمل هذه الخدمة مع موردي CA لإصدار الشهادة، التي تتضمن قائمة SAN وحقل CN من الخطوة السابقة.
7. **التخزين المحلي**: يكتب شهادة x509 الصادرة حديثًا من الخطوة الأخيرة ومفتاحها الخاص المقابل (الذي تم إنشاؤه سابقًا) إلى التخزين المحلي، مما يجعلهما متاحين للخدمات التي تعمل على مثيل العقدة.

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

#### استخدم شهاداتك الخاصة (BYOC)

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

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

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

* **شهادة بدل عام**
* **شهادة متعددة 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 %}

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

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

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

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

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

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

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

تُعد الشهادة متعددة 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 Zone.

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