# اعتبارات نشر 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) لخيارات النشر المختلفة.

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

<figure><img src="/files/962dc3b817005332a33fd8dade9f42e934679666" 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="/files/98bb00c7ec2ba0e51e0110dcd779e691917edf8a" alt=""><figcaption></figcaption></figure>

توضح الصورة أعلاه الحد الأدنى من التكوين المطلوب للنشر **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 Local Survivability |

**تكوين شهادة 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**.

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

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

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

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

<figure><img src="/files/82c9c6e3a0703a21af96420fdbd8e0dbfb350e70" alt=""><figcaption></figcaption></figure>

تكرر هذه الإعدادات بنية Node كما هو موضح في مخطط اجتماعات 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                                                        |

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

<figure><img src="/files/b20030ada95090f20802d06dadccd3d5bd322b6c" alt=""><figcaption></figcaption></figure>

تُظهر الصورة أعلاه نشرًا minimal 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) | نظام التشغيل الخاص بـ Node وZPLS يشاركان عنوان بروتوكول الإنترنت (IP) واحدًا |
| قيد النشر                                      | يُسمح بوحدة واحدة فقط لكل جهاز VM الخاص بـ Node (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 التكاليف المرتبطة بالتسجيل والتجديد.
* **إحضار شهادتك الخاصة (BYOC)**&#x200E;: مع هذا الخيار، تقوم بتوفير شهاداتك الخاصة، الموقعة من أي جهة 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)

{% 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 أن تشفر حركة المرور من أي اسم مضيف في النطاق. على سبيل المثال: يمكن لشهادة wildcard مثل \*.customer.com أن تشفر حركة المرور من `host1.customer.com` و `host2.customer.com` أو أي اسم ضمن `.customer.com`.

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

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

**شهادات Multi-SAN أو Multi-Domain أو SAN أو UCC**

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

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

تُعد شهادة 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 وجميع أسماء مضيفي الخدمات المنشورة على العقد في منطقة DNS.

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://library.zoom.com/technical-library/technical-library-ar/alkhdmat-almtqdmh-lkhth-enterprise/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.