> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/es/servicios-empresarial-avanzados/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md).

# Consideraciones de implementación de Zoom Node

Esta sección contiene varios ejemplos de cómo Zoom Node puede dar Soporte a varios módulos de servicio como Zoom Meetings Hybrid y Zoom Phone Local Survivability (ZPLS). Las implementaciones típicas con una Dirección IP dedicada pueden verse como la siguiente colección de diagramas.

Cada servicio implementado en Zoom Node requiere una Dirección IP única. Un Zoom Node tendrá hasta cinco (5) Direcciones IP asignadas si al Node se le ha asignado una dirección específica para la administración y una para cada servicio implementado (hasta cuatro) en el Node. Un Zoom Node que ejecuta un solo servicio (como ZPLS) puede implementarse con una sola Dirección IP si el Node y el servicio están asignados para compartir la misma Dirección IP.

A continuación se muestran varias opciones de implementación. Tenga en cuenta la cantidad de IP y certificados (CN/SAN) para las distintas opciones de implementación.

### <mark style="color:azul;">Opción 1: Zoom Meetings Hybrid implementado con IP y nombres de host dedicados</mark>

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

La imagen de arriba resume los requisitos de configuración de IP y certificado para implementar **Zoom Meetings Hybrid** en entornos locales o de nube híbrida.

La siguiente tabla desglosa el Node de ejemplo e incluye sus módulos de servicio de proxy activo y MMR:

| Componente                    | Nombre de host       | Rol, función del certificado TLS    | Función                                 |
| ----------------------------- | -------------------- | ----------------------------------- | --------------------------------------- |
| SO del Node                   | `node1.customer.com` | Nombre común (CN)                   | Orquestación central                    |
| Proxy de Zoom Conector        | `zcp1.customer.com`  | Nombre alternativo del sujeto (SAN) | Señalización y control de sesión        |
| Router de módulo multimedia 1 | `mmr1.customer.com`  | Nombre alternativo del sujeto (SAN) | Enrutamiento y procesamiento multimedia |
| Router de módulo multimedia 2 | `mmr2.customer.com`  | Nombre alternativo del sujeto (SAN) | Enrutamiento y procesamiento multimedia |
| Router de módulo multimedia 3 | `mmr3.customer.com`  | Nombre alternativo del sujeto (SAN) | Enrutamiento y procesamiento multimedia |

{% hint style="info" %}
Debe Asignar a cada módulo una Dirección IP estática dedicada. Total de Direcciones IP requeridas: cinco (5)
{% endhint %}

<figure><img src="/files/53e024cf8a5d7680a3b774ee406740202da4f3e7" alt=""><figcaption></figcaption></figure>

La imagen de arriba describe la configuración mínima necesaria para implementar **Zoom Phone Local Survivability (ZPLS)**. ZPLS permite la disponibilidad continua del servicio telefónico en caso de interrupción de internet o de la nube al ejecutar la lógica de supervivencia localmente en una VM de Zoom Node.

Los siguientes nombres de host deben configurarse en DNS e incluirse en el certificado TLS:

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

**Asignación funcional del nombre de host**

| Componente  | Nombre de host       | Rol, función del certificado TLS | Función                                  |
| ----------- | -------------------- | -------------------------------- | ---------------------------------------- |
| SO del Node | `node1.customer.com` | Nombre común (CN)                | Orquestación central                     |
| Módulo ZPLS | `zplsl.customer.com` | Nombre alternativo del sujeto    | Lógica de Zoom Phone Local Survivability |

**Configuración del certificado TLS**

| Campo                           | Valor                |
| ------------------------------- | -------------------- |
| Nombre común (CN)               | `node1.customer.com` |
| Nombres alternativos del sujeto | `zplsl.customer.com` |

Los certificados deben generarse u obtenerse (CA pública o privada) para incluir tanto el CN como los SAN enumerados arriba. Esto permite una validación TLS adecuada para una comunicación segura entre módulos.

**Requisitos de Dirección IP**

| Métrica                            | Valor / Descripción                                 |
| ---------------------------------- | --------------------------------------------------- |
| Total de Direcciones IP requeridas | 5 (asignación general)                              |
| Usado en el contexto de ZPLS       | 2 IP (1 para el SO del Node, 1 para el módulo ZPLS) |

Aunque se requieren cinco (5) IP para la implementación general, **solo dos (2) Direcciones IP se usan activamente** en la implementación de ZPLS: uno por módulo, ejecutándose en una **VM de Node dedicada**.

{% hint style="warning" %}
ZPLS solo permite un módulo por VM de Node. No puede ubicar conjuntamente ZPLS con otros módulos de Zoom en la misma VM.
{% endhint %}

¿Cómo se comparan estos diagramas? La primera imagen muestra un ejemplo de una implementación híbrida de Zoom Meetings. La segunda imagen muestra un ejemplo de una implementación de capacidad de supervivencia local de Zoom Phone.

Puede compartir la primera IP/nombre de anfitrión entre el SO y el primer módulo, si lo desea, para reducir la cantidad de direcciones IP, nombres de anfitrión y Nombres Alternativos del Sujeto (SAN) requeridos.

### <mark style="color:azul;">Opción 2: Zoom Meetings Hybrid implementado con una IP compartida y un nombre de anfitrión compartido</mark>

<figure><img src="/files/6399a01c2b7e5fa5c962359d3ffe621f6c7572cc" alt=""><figcaption></figcaption></figure>

Esta configuración repite la estructura de Node como se ve en el diagrama de la Opción 1 de Zoom Meetings Hybrid. Sin embargo, en esta implementación, el **SO de Node comparte su Dirección IP con el primer módulo implementado** (normalmente, el Zoom Conector Proxy, ZCP). Esto da como resultado una menor utilización de IP, a la vez que mantiene los requisitos funcionales y de TLS.

Los siguientes nombres de host deben configurarse en DNS e incluirse en el certificado TLS:

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

**Asignación funcional del nombre de host**

| Componente                    | Nombre de host      | Rol, función del certificado TLS    | Función                                 |
| ----------------------------- | ------------------- | ----------------------------------- | --------------------------------------- |
| ZCP (Zoom Conector Proxy)     | `zcp1.customer.com` | Nombre común (CN)                   | Señalización y control de sesión        |
| Router de módulo multimedia 1 | `mmr1.customer.com` | Nombre alternativo del sujeto (SAN) | Enrutamiento y procesamiento multimedia |
| Router de módulo multimedia 2 | `mmr2.customer.com` | Nombre alternativo del sujeto (SAN) | Enrutamiento y procesamiento multimedia |
| Router de módulo multimedia 3 | `mmr3.customer.com` | Nombre alternativo del sujeto (SAN) | Enrutamiento y procesamiento multimedia |

**Configuración del certificado TLS**

| Campo                           | Valor                                                         |
| ------------------------------- | ------------------------------------------------------------- |
| Nombre común (CN)               | `zcp1.customer.com`                                           |
| Nombres alternativos del sujeto | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` |

Los certificados deben incluir todos los SAN para admitir una comunicación TLS segura entre Zoom Node y los módulos de Zoom instalados.

**Requisitos de Dirección IP**

| Métrica                            | Valor / Descripción                                  |
| ---------------------------------- | ---------------------------------------------------- |
| Total de Direcciones IP requeridas | 4                                                    |
| Estrategia de uso compartido de IP | El SO de Node comparte IP con el primer módulo (ZCP) |
| IPs individuales requeridas para   | ZCP/MMR1, MMR2, MMR3                                 |

{% hint style="info" %}
Cuando la Dirección IP está **compartida** entre el SO de Node y el primer módulo implementado (ZCP), solo **cuatro (4) direcciones IP** son necesarias. Este diseño optimiza el uso de IP y, al mismo tiempo, cumple con los estándares de implementación.
{% endhint %}

<figure><img src="/files/8312a4506898f4fd4e9f89e7d47a493cf89619b6" alt=""><figcaption></figcaption></figure>

La imagen anterior muestra una implementación mínima de ZPLS donde el **SO de Node comparte su Dirección IP con el módulo ZPLS instalado**. Este es el **único escenario** en el marco de Zoom Node donde un **certificado TLS de un solo anfitrión** es válido.

El siguiente nombre de anfitrión debe configurarse en DNS e incluirse en el certificado TLS:

* `zplsl.customer.com`

**Asignación funcional del nombre de host**

| Componente  | Nombre de host       | Rol, función del certificado TLS | Función                                  |
| ----------- | -------------------- | -------------------------------- | ---------------------------------------- |
| Módulo ZPLS | `zplsl.customer.com` | Nombre común (CN)                | Lógica de Zoom Phone Local Survivability |

**Configuración del certificado TLS**

| Campo             | Valor               |
| ----------------- | ------------------- |
| Nombre común (CN) | `zcp1.customer.com` |
| SANs              | (no requerido)      |

En esta configuración, un certificado de un solo anfitrión es suficiente, ya que tanto el SO como el módulo ZPLS comparten el mismo nombre de anfitrión y la misma Dirección IP.

**Requisitos de Dirección IP**

| Métrica                            | Valor / Descripción                                  |
| ---------------------------------- | ---------------------------------------------------- |
| Total de Direcciones IP requeridas | 1                                                    |
| Estrategia de uso compartido de IP | El SO de Node y ZPLS comparten una sola Dirección IP |
| Restricción de implementación      | Solo se permite un módulo por VM de Node (solo ZPLS) |

{% hint style="warning" %}
ZPLS es el único escenario compatible en la arquitectura de Zoom Node donde:

* Se acepta un certificado de un solo anfitrión (solo CN)
* Solo se requiere una (1) Dirección IP para la implementación debido al uso compartido de IP entre SO y módulo
* No se admite la ubicación conjunta de módulos adicionales en la misma VM
  {% endhint %}

### <mark style="color:azul;">Decida qué método de gestión de certificados funciona mejor para sus implementaciones</mark>

Cada módulo de servicio implementado en Zoom Node requiere un certificado válido firmado por una Autoridad de Certificación (CA) de confianza pública de la lista de confianza de certificados de Zoom Node. Esto incluye autoridades públicas conocidas.

Zoom Node ofrece dos métodos de gestión de certificados:

* **PKI automática**: Esta solución innovadora automatiza la inscripción y renovación seguras de certificados con Autoridades de Certificación (CA) de confianza pública. Zoom cubre los costos asociados con la inscripción y la renovación.
* **Traiga su propio certificado (BYOC)**: Con esta opción, usted proporciona sus propios certificados, firmados por cualquier CA principal de confianza pública. Usted se encarga de la inscripción y las renovaciones de certificados. Se aplican consideraciones adicionales con respecto al potencial de Zoom Node de admitir hasta cinco nombres de anfitrión/SAN cuando se utilizan certificados proporcionados por el cliente, lo cual se detalla más abajo.

#### Gestión automática de certificados con Auto PKI

Zoom Auto PKI instala automáticamente certificados de CA válidos y de confianza pública para la plataforma Zoom Node, así como para cualquier módulo implementado en ella. La renovación de certificados también se gestiona automáticamente. Esto simplifica la gestión de certificados para todos los servicios y para el propio Zoom Node.

#### Comprender la inscripción y renovación de certificados de Auto PKI

El siguiente escenario puede ayudarle a comprender cómo funciona la inscripción y renovación de certificados.

Por ejemplo: Un administrador ha implementado una nueva instancia de Node. Cada instancia requiere un certificado x509 válido. **La clave privada del certificado nunca debe salir de esta instancia**.

El proceso Auto PKI realiza los siguientes pasos:

1. **Recuperación de plantillas**: Obtiene todas las plantillas de configuración compatibles, incluidas las opciones para varios proveedores de CA, del servicio Auto PKI en la nube de Zoom.
2. **Recopilación de Direcciones IP**: Reúne todas las Direcciones IP utilizadas por los servicios que se ejecutan en el nodo y las envía al servicio Auto PKI en la nube de Zoom.
3. **Aprovisionamiento de nombres DNS**: El servicio Auto PKI en la nube devuelve un conjunto de nombres DNS en el formato `<instance_identificador>.<customer_identificador>.zoomonprem.com`. Estos dominios se configuran con registros A/AAAA.
4. **Solicitud de nombre DNS reservado**: Solicita un nombre DNS reservado en el formato `rsvd-<randomized_string>.<customer_identificador>.zoomonprem.com`.
5. **Generación de solicitud de certificado**: Genera una solicitud de certificado x509, usando los nombres DNS del tercer paso en el campo SAN y el nombre reservado del cuarto paso en el campo Common Name (CN).
6. **Emisión de certificado**: Envía la Solicitud de Firma de certificado (CSR) al servicio Auto PKI en la nube de Zoom. Luego, este servicio trabaja con proveedores de CA para emitir el certificado, lo que incluye la lista SAN y el campo CN del paso anterior.
7. **Almacenamiento local**: Escribe en el almacenamiento local el certificado x509 recién emitido del último paso y su clave privada correspondiente (generada anteriormente), poniéndolos a disposición de los servicios que se ejecutan en la instancia de Node.

Auto PKI simplifica la gestión de certificados en Zoom Node al supervisar automáticamente las fechas de vencimiento y solicitar nuevos certificados, eliminando la necesidad de renovación manual.

#### Traiga sus propios certificados (BYOC)

Puede instalar sus propios certificados válidos y firmados públicamente en Zoom Node usando la interfaz web local. Puede hacerlo durante la instalación inicial o en un momento posterior. El proceso resultará familiar para quienes estén acostumbrados a instalar certificados en aplicaciones basadas en la web.

Si opta por usar sus propios certificados, recuerde que el certificado estará en un servidor que se comunica con varios nombres de host. Por lo tanto, el tipo de certificado que Seleccione debe admitir cifrado para el tráfico originado desde más de un nombre de host (CN del certificado). Todos los nombres de host utilizados para Node y cualquier servicio implementado deben poder resolverse públicamente por los servicios de la nube de Zoom.

Zoom recomienda dos tipos de certificados:

* **Certificado comodín**
* **Certificado Multi-SAN** (también conocido como certificado multidominio, certificado SAN o certificado UCC)

{% hint style="danger" %}
Un certificado de anfitrión único típico no funcionará con Zoom Node, excepto en el escenario específico en el que una sola Dirección IP y nombre de anfitrión se comparten entre Zoom Node y un solo módulo. Para contexto adicional, consulte el diagrama de ZPLS en el [#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 %}

**Certificados comodín: recomendados por su simplicidad**

Un certificado comodín puede cifrar el tráfico de cualquier nombre de host en el dominio. Por ejemplo: un certificado comodín como \*.customer.com puede cifrar el tráfico de `host1.customer.com` y `host2.customer.com` o cualquier nombre dentro de `.customer.com`.

Cuando implementas Zoom Node e instalas el certificado comodín, cifrará automáticamente el tráfico de cualquier servicio que implementes en el Node, con el requisito de que todos los Servicios implementados utilicen un Nombre de Dominio Totalmente Calificado (FQDN) del dominio comodín.

Esto minimiza el esfuerzo para implementar servicios en el Node: no necesitas conocer los nombres de los servicios antes de implementarlos. Sin embargo, necesitas conocer los nombres de los servicios si usas el método de certificado multi-SAN.

**Certificados Multi-SAN, Multi-Dominio, SAN o UCC**

{% hint style="warning" %}
Debes conocer los nombres de host y las direcciones IP que usarás para el Node (hasta uno \[1]) y cualquier Servicio que instalarás (hasta cuatro \[4]).

**Esta información es necesaria antes de registrar un certificado**.
{% endhint %}

Se necesita un certificado Multi-SAN para Zoom Node porque cifra el tráfico de cinco (5) nombres de host. Una solicitud única de este certificado requiere conocer de antemano toda la información necesaria, incluidos los nombres planificados del Node y los nombres de todos los servicios previstos para su implementación en el Node. Por ejemplo, con un módulo como ZPLS, solo se implementa un módulo ZPLS por Node, por lo que solo se necesita un SAN adicional para el nombre de host del servicio ZPLS.

La siguiente tabla puede usarse como un ejemplo:

| Nombre de host (SAN)                        | Dirección 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-seminario web.company.com`            | `10.1.50.102` |
| (Servicio 4 - no utilizado en este ejemplo) | (N/D)         |

Este ejemplo es una configuración típica, con un nodo que aloja ZPLS en la misma IP más dos servicios adicionales en IPs separadas. Reemplace “company.com” con su dominio real y use las direcciones IP de su red.

**Requisitos de resolución DNS**

Zoom requiere que los nombres de host sean resolubles públicamente para que se pueda establecer una confianza bidireccional. Todos los nombres de host de Zoom Node y todos los nombres de host de servicio implementados en los Nodes deben incluirse en la zona DNS.

Si su Organización ejecuta servicios o dominios DNS internos y externos separados, los nombres de host de Zoom Node deben alojarse en una zona que sea resoluble por sus servidores DNS externos (puede restringirse para que solo resuelva para rangos de IP de Zoom). Sus usuarios internos de Zoom y la nube de Zoom deben comunicarse usando el mismo conjunto de nombres de host.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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/es/servicios-empresarial-avanzados/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.