Consideraciones de implementación de Zoom Node
Más información sobre cómo diversos ejemplos de implementación respaldan Zoom Node y los módulos de servicio 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 Supervivencia local (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 Nodo se le ha asignado una dirección específica para la administración y una para cada servicio implementado (hasta cuatro) en el Nodo. Un Zoom Node que ejecute un solo servicio (como ZPLS) puede implementarse con una sola Dirección IP si al Nodo y al servicio se les asigna compartir la misma Dirección IP.
A continuación se muestran varias opciones de implementación. Observe el número de IP y certificados (CN/SAN) para las distintas opciones de implementación.
Opción 1: Zoom Meetings Hybrid implementado con Direcciones IP y nombres de host dedicados
La imagen anterior resume los requisitos de configuración de Dirección IP y certificado para implementar Zoom Meetings Hybrid en entornos locales o de nube híbrida.
La tabla siguiente desglosa el Zoom Node de ejemplo e incluye sus módulos de servicio de proxy activo y MMR:
SO del nodo
node1.customer.com
Nombre común (CN)
Orquestación central
Proxy Conector de Zoom
zcp1.customer.com
Nombre alternativo del sujeto (SAN)
Señalización y control de sesión
Enrutador del módulo de medios 1
mmr1.customer.com
Nombre alternativo del sujeto (SAN)
Enrutamiento y procesamiento de medios
Enrutador del módulo de medios 2
mmr2.customer.com
Nombre alternativo del sujeto (SAN)
Enrutamiento y procesamiento de medios
Enrutador del módulo de medios 3
mmr3.customer.com
Nombre alternativo del sujeto (SAN)
Enrutamiento y procesamiento de medios
La imagen anterior describe la configuración mínima necesaria para implementar Zoom Phone Local Survivability (ZPLS). ZPLS permite que la disponibilidad del servicio telefónico continúe en caso de una interrupción de Internet o de la nube, ejecutando 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.comzplsl.customer.com
Asignación funcional de nombres de host
SO del nodo
node1.customer.com
Nombre común (CN)
Orquestación central
Módulo ZPLS
zplsl.customer.com
Nombre alternativo del sujeto
Lógica de supervivencia local de Zoom Phone
Configuración del certificado TLS
Nombre común (CN)
node1.customer.com
Nombres alternativos del sujeto
zplsl.customer.com
Los certificados deben generarse o adquirirse (CA pública o privada) para incluir tanto el CN como los SAN enumerados anteriormente. Esto permite una validación TLS adecuada para una comunicación segura entre módulos.
Requisitos de Dirección IP
Total de Direcciones IP requeridas
5 (asignación general)
Usado en el contexto de ZPLS
2 Direcciones IP (1 para el SO del nodo, 1 para el módulo ZPLS)
Aunque se requieren cinco (5) Direcciones IP para la implementación general, solo se usan activamente dos (2) Direcciones IP en la implementación de ZPLS: una por módulo, ejecutándose en una VM de Node dedicada.
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.
¿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 supervivencia local de Zoom Phone.
Puede compartir la primera Dirección IP/nombre de anfitrión entre el SO y el primer módulo, si lo desea, para reducir el número de Direcciones IP, nombres de anfitrión y nombres alternativos del sujeto (SAN) necesarios.
Opción 2: Zoom Meetings Hybrid implementado con una Dirección IP y un nombre de anfitrión compartidos
Esta configuración repite la estructura de Node que se observa en el diagrama de Zoom Meetings Hybrid de la opción 1. Sin embargo, en esta implementación, el El SO de Node comparte su Dirección IP con el primer módulo implementado (normalmente el proxy de Zoom Conector, ZCP). Esto reduce la utilización de IP y mantiene los requisitos funcionales y de TLS.
Los siguientes nombres de host deben configurarse en DNS e incluirse en el certificado TLS:
zcp1.customer.commmr1.customer.commmr2.customer.commmr3.customer.com
Asignación funcional de nombres de host
ZCP (proxy de Zoom Conector)
zcp1.customer.com
Nombre común (CN)
Señalización y control de sesión
Enrutador del módulo de medios 1
mmr1.customer.com
Nombre alternativo del sujeto (SAN)
Enrutamiento y procesamiento de medios
Enrutador del módulo de medios 2
mmr2.customer.com
Nombre alternativo del sujeto (SAN)
Enrutamiento y procesamiento de medios
Enrutador del módulo de medios 3
mmr3.customer.com
Nombre alternativo del sujeto (SAN)
Enrutamiento y procesamiento de medios
Configuración del certificado TLS
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
Total de Direcciones IP requeridas
4
Estrategia para compartir IP
El SO de Node comparte IP con el primer módulo (ZCP)
Se requieren Direcciones IP individuales para
ZCP/MMR1, MMR2, MMR3
La imagen anterior muestra una implementación mínima de ZPLS en la que el 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 de nombres de host
Módulo ZPLS
zplsl.customer.com
Nombre común (CN)
Lógica de supervivencia local de Zoom Phone
Configuración del certificado TLS
Nombre común (CN)
zcp1.customer.com
SAN
(no requerido)
En esta configuración, basta con un certificado de un solo anfitrión, ya que tanto el SO como el módulo ZPLS comparten el mismo nombre de anfitrión y Dirección IP.
Requisitos de Dirección IP
Total de Direcciones IP requeridas
1
Estrategia para compartir 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)
ZPLS es el único escenario compatible en la arquitectura de Zoom Node en el que:
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 el SO y el módulo
No se admite la ubicación conjunta de módulos adicionales en la misma VM
Decida qué método de administración de certificados funciona mejor para sus implementaciones
Cada módulo de servicio implementado en Zoom Node requiere un certificado válido firmado por una entidad de certificación (CA) de confianza pública de la lista de confianza de certificados de Zoom Node. Esto incluye autoridades públicas reconocidas.
Zoom Node ofrece dos métodos de administración de certificados:
PKI automática: Esta solución innovadora automatiza la inscripción y renovación seguras de certificados con entidades 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 renovación de los certificados. Se aplican consideraciones adicionales respecto al potencial de Zoom Node de tener hasta cinco nombres de anfitrión/SAN al usar certificados proporcionados por el cliente, que se detallan más adelante.
Administración automática de certificados con PKI automática
Zoom Auto PKI instala automáticamente certificados de CA válidos y de confianza pública para la plataforma Zoom Node, así como para los módulos implementados en ella. La renovación de certificados también se gestiona automáticamente. Esto simplifica la administración de certificados para todos los servicios y para Zoom Node.
Comprender la inscripción y renovación de certificados de PKI automática
El siguiente escenario puede ayudarle a comprender cómo funcionan la inscripción y la 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 de Auto PKI realiza los siguientes pasos:
Recuperación de plantilla: Obtiene todas las plantillas de configuración compatibles, incluidas las opciones para varios proveedores de CA, del servicio de Auto PKI en la nube de Zoom.
Recopilación de Dirección IP: Recopila todas las direcciones IP utilizadas por los servicios que se ejecutan en el nodo y las envía al servicio de Auto PKI en la nube de Zoom.
Aprovisionamiento de nombre DNS: El servicio en la nube de Auto PKI devuelve un conjunto de nombres DNS en el formato
<identificador_de_instancia>.<identificador_de_cliente>.zoomonprem.com. Estos dominios se configuran con registros A/AAAA.Solicitud de nombre DNS reservado: Solicita un nombre DNS reservado en el formato
rsvd-<randomized_string>.<customer_identificador>.zoomonprem.com.Generación de solicitud de certificado: Genera una solicitud de certificado x509, utilizando los nombres DNS del tercer paso en el campo SAN y el nombre reservado del cuarto paso en el campo Nombre común (CN).
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, que incluye la lista SAN y el campo CN del paso anterior.
Almacenamiento local: Escribe el certificado x509 recién emitido del paso anterior y su correspondiente clave privada (generada anteriormente) en el almacenamiento local, 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 expiración y solicitar nuevos certificados, eliminando la necesidad de renovación manual.
Traiga sus propios certificados (BYOC)
Puede instalar sus propios certificados válidos, firmados públicamente, en Zoom Node mediante la interfaz web local. Puede hacerlo durante la instalación inicial o en un momento posterior. El proceso les resultará familiar a 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 desplegado deben ser resolubles 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)
Un certificado típico de un solo anfitrión no funcionará con Zoom Node, excepto en el escenario específico en el que se comparten una sola Dirección IP y un nombre de anfitrión entre Zoom Node y un solo módulo. Para obtener contexto adicional, consulte el diagrama ZPLS en el Consideraciones de implementación de Zoom Node sección.
Certificados comodín: recomendados por simplicidad
Un certificado comodín puede cifrar el tráfico de cualquier nombre de host del 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 wildcard, cifrará automáticamente el tráfico para cualquier servicio que implementes en el nodo, con el requisito de que todos los servicios desplegados utilicen un Nombre de dominio completamente calificado (FQDN) del dominio wildcard.
Esto minimiza el esfuerzo para desplegar servicios en el nodo: no necesitas conocer los nombres de los servicios antes de desplegarlos. 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
Debes conocer los nombres de host y las direcciones IP que usarás para el nodo (hasta uno [1]) y cualquier servicio que vayas a instalar (hasta cuatro [4]).
Esta información es necesaria antes de registrar un certificado.
Se necesita un certificado Multi-SAN para Zoom Node porque cifra el tráfico de cinco (5) nombres de host. Una única solicitud para este certificado requiere conocer de antemano toda la información necesaria, incluidos los nombres previstos del nodo y los nombres de todos los servicios previstos para su despliegue en el nodo. Por ejemplo, con un módulo como ZPLS, solo se despliega un módulo ZPLS por nodo, por lo que solo se necesita un SAN adicional para el nombre de host del servicio ZPLS.
La tabla siguiente puede usarse como ejemplo:
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 usado 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 servicios implementados en los nodos 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 estar alojados en una zona que pueda resolverse con 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 necesitan comunicarse usando el mismo conjunto de nombres de host.
Última actualización
¿Te fue útil?