Consideraciones de despliegue de Zoom Node
Aprenda más sobre cómo diversos ejemplos de despliegue admiten Zoom Node y los módulos de servicio de Zoom Node
Esta sección contiene varios ejemplos de cómo Zoom Node puede soportar 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 tener el aspecto de 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 por cada servicio implementado (hasta cuatro) en el Node. Un Zoom Node que ejecute un único servicio (como ZPLS) puede implementarse con una sola dirección IP si al Node 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/SANs) para las distintas opciones de implementación.
Opción 1: Zoom Meetings Hybrid implementado con IP y nombres de host dedicados
La imagen anterior resume los requisitos de configuración de IP y certificados para implementar Zoom Meetings Hybrid en entornos on-premises o en la nube híbrida.
La tabla siguiente desglosa el Node de ejemplo e incluye su proxy activo y los Módulos de Servicio MMR:
SO del Node
node1.customer.com
Nombre común (CN)
Orquestación principal
Zoom Connector Proxy
zcp1.customer.com
Nombre alternativo de sujeto (SAN)
Señalización y control de sesión
Router del módulo de medios 1
mmr1.customer.com
Nombre alternativo de sujeto (SAN)
Enrutamiento y procesamiento de medios
Router del módulo de medios 2
mmr2.customer.com
Nombre alternativo de sujeto (SAN)
Enrutamiento y procesamiento de medios
Router del módulo de medios 3
mmr3.customer.com
Nombre alternativo de sujeto (SAN)
Enrutamiento y procesamiento de medios
Debe asignar a cada módulo una dirección IP estática dedicada. Total de direcciones IP requeridas: cinco (5)
La imagen anterior describe la configuración mínima necesaria para implementar Zoom Phone Local Survivability (ZPLS). ZPLS permite la continuidad 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 del Zoom Node.
Los siguientes nombres de host deben configurarse en DNS e incluirse en el certificado TLS:
node1.customer.comzplsl.customer.com
Mapeo funcional del nombre de host
SO del Node
node1.customer.com
Nombre común (CN)
Orquestación principal
Módulo ZPLS
zplsl.customer.com
Nombre alternativo de sujeto
Lógica de Zoom Phone Local Survivability
Configuración del certificado TLS
Nombre común (CN)
node1.customer.com
Nombres alternativos de sujeto
zplsl.customer.com
Los certificados deben generarse o procurarse (CA pública o privada) para incluir tanto el CN como los SANs listados arriba. Esto permite una validación TLS adecuada para la comunicación segura entre módulos.
Requisitos de direcciones IP
Total de direcciones IP requeridas
5 (asignación general)
Usado en el contexto de ZPLS
2 IPs (1 para el SO del Node, 1 para el módulo ZPLS)
Aunque se requieren cinco (5) IPs para una 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 del Node. No se puede coubicar ZPLS con otros módulos de Zoom en la misma VM.
¿Cómo comparan estos diagramas? La primera imagen muestra un ejemplo de una implementación de Zoom Meetings Hybrid. La segunda imagen muestra un ejemplo de una implementación de Zoom Phone Local Survivability.
Puede compartir la primera IP/nombre de host entre el SO y el primer módulo, si lo desea, para reducir el número de direcciones IP, nombres de host y Nombres Alternativos de Sujeto (SANs) requeridos.
Opción 2: Zoom Meetings Hybrid implementado con IP compartida y nombre de host compartido
Esta configuración repite la estructura del Node como se ve en el diagrama de Zoom Meetings Hybrid de la Opción 1. Sin embargo, en esta implementación, el SO del Node comparte su dirección IP con el primer módulo implementado (típicamente el Zoom Connector Proxy, ZCP). Esto resulta en una menor utilización de IP manteniendo los requisitos TLS y funcionales.
Los siguientes nombres de host deben configurarse en DNS e incluirse en el certificado TLS:
zcp1.customer.commmr1.customer.commmr2.customer.commmr3.customer.com
Mapeo funcional del nombre de host
ZCP (Zoom Connector Proxy)
zcp1.customer.com
Nombre común (CN)
Señalización y control de sesión
Router del módulo de medios 1
mmr1.customer.com
Nombre alternativo de sujeto (SAN)
Enrutamiento y procesamiento de medios
Router del módulo de medios 2
mmr2.customer.com
Nombre alternativo de sujeto (SAN)
Enrutamiento y procesamiento de medios
Router del módulo de medios 3
mmr3.customer.com
Nombre alternativo de sujeto (SAN)
Enrutamiento y procesamiento de medios
Configuración del certificado TLS
Nombre común (CN)
zcp1.customer.com
Nombres alternativos de sujeto
mmr1.customer.com, mmr2.customer.com, mmr3.customer.com
Los certificados deben incluir todos los SANs para admitir la comunicación TLS segura entre el Zoom Node y los módulos de Zoom instalados.
Requisitos de direcciones IP
Total de direcciones IP requeridas
4
Estrategia de compartición de IP
El SO del Node comparte IP con el primer módulo (ZCP)
IPs individuales requeridas para
ZCP/MMR1, MMR2, MMR3
Cuando la dirección IP se comparte entre el SO del Node y el primer módulo implementado (ZCP), solo cuatro (4) direcciones IP son necesarias. Este diseño optimiza el uso de IP mientras sigue cumpliendo con los estándares de implementación.
La imagen anterior muestra una implementación mínima de ZPLS donde el SO del 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 host único es válido.
El siguiente nombre de host debe configurarse en DNS e incluirse en el certificado TLS:
zplsl.customer.com
Mapeo funcional del nombre de host
Módulo ZPLS
zplsl.customer.com
Nombre común (CN)
Lógica de Zoom Phone Local Survivability
Configuración del certificado TLS
Nombre común (CN)
zcp1.customer.com
SANs
(no requerido)
En esta configuración, un certificado de host único es suficiente ya que tanto el SO como el módulo ZPLS comparten el mismo nombre de host y dirección IP.
Requisitos de direcciones IP
Total de direcciones IP requeridas
1
Estrategia de compartición de IP
El SO del Node y ZPLS comparten una única dirección IP
Restricción de implementación
Solo se permite un módulo por VM del Node (solo ZPLS)
ZPLS es el único escenario compatible en la arquitectura de Zoom Node donde:
Un certificado de host único (solo CN) es aceptable
Solo se requiere una (1) dirección IP para la implementación debido al intercambio de IP entre el SO y el módulo
No se admite la co-ubicación de módulos adicionales en la misma VM
Decida qué método de gestió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 Autoridad de Certificación (CA) públicamente confiable de la lista de confianza de certificados de Zoom Node. Esto incluye autoridades públicas reconocidas.
Zoom Node ofrece dos métodos de gestión de certificados:
Auto PKI: Esta solución innovadora automatiza la inscripción y renovación segura de certificados con Autoridades de Certificación (CAs) públicamente confiables. 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 pública de prestigio. Usted se encarga de la inscripción y la renovación de los certificados. Se aplican consideraciones adicionales con respecto a la posibilidad de Zoom Node de hasta cinco nombres de host/SANs cuando se usan certificados proporcionados por el cliente, las cuales se detallan más abajo.
Gestión automática de certificados con Auto PKI
Zoom Auto PKI instala automáticamente certificados CA válidos y públicamente confiables para la plataforma Zoom Node, así como para los módulos que se implementen 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 Auto PKI
El siguiente escenario puede ayudarle a entender 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:
Recuperación de plantilla: Obtiene todas las plantillas de configuración admitidas, incluidas las opciones para varios proveedores de CA, desde el servicio Auto PKI en la nube de Zoom.
Colección de direcciones IP: Reúne todas las direcciones IP utilizadas por los servicios que se ejecutan en el Node y las envía al servicio Auto PKI en la nube de Zoom.
Aprovisionamiento de nombres DNS: El servicio en la nube Auto PKI devuelve un conjunto de nombres DNS en el formato
<instance_identifier>.<customer_identifier>.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_identifier>.zoomonprem.com.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 de Nombre Común (CN).
Emisión del certificado: Envía la Solicitud de Firma de Certificado (CSR) al servicio Auto PKI en la nube de Zoom. Este servicio luego trabaja con los proveedores de CA para emitir el certificado, que incluye la lista de SAN y el campo CN del paso anterior.
Almacenamiento local: Escribe el certificado x509 recién emitido del paso anterior y su clave privada correspondiente (generada anteriormente) en el almacenamiento local, poniéndolos a disposición de los servicios que se ejecutan en la instancia del 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 mediante la interfaz web local. Puede hacerlo durante la instalación inicial o en un momento posterior. El proceso será familiar para quienes están acostumbrados a instalar certificados en aplicaciones 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 elija debe admitir el cifrado para el tráfico originado desde más de un nombre de host (CN del certificado). Todos los nombres de host utilizados para el Node y cualquier servicio implementado deben ser resolubles públicamente por los servicios en la nube de Zoom.
Zoom recomienda dos tipos de certificados:
Certificado comodín
Certificado Multi-SAN (también conocido como Certificado Multi-Dominio, Certificado SAN o Certificado UCC)
Un certificado típico de host único no funcionará con Zoom Node, excepto para el escenario específico en el que una única dirección IP y nombre de host se comparten entre Zoom Node y un único módulo. Para obtener contexto adicional, consulte el diagrama ZPLS en el Consideraciones de despliegue de Zoom Node sección.
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 como host2.customer.com o cualquier nombre dentro de .customer.com.
Cuando implemente Zoom Node e instale el certificado comodín, cifrará automáticamente el tráfico de cualquier servicio que implemente en el Node con el requisito de que todos los servicios implementados usen un Nombre de Dominio Totalmente Calificado (FQDN) del dominio comodín.
Esto minimiza el esfuerzo para implementar servicios en el Node: no necesita conocer los nombres de los servicios antes de implementarlos. Sin embargo, necesita conocer los nombres de servicio si usa el método de Certificado multi-SAN.
Certificados Multi-SAN, Multi-Dominio, SAN o UCC
Debe conocer los nombres de host y las direcciones IP que utilizará para el Node (hasta uno [1]) y cualquier Servicio que vaya a instalar (hasta cuatro [4]).
Esta información es necesaria antes de inscribir un certificado.
Un certificado Multi-SAN es necesario para Zoom Node porque cifra el tráfico de cinco (5) nombres de host. Una solicitud única para este certificado requiere el conocimiento previo de toda la información necesaria, incluidos los nombres previstos del Node y los nombres de todos los servicios previstos para implementar 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 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-webinar.company.com
10.1.50.102
(Servicio 4 - no utilizado en este ejemplo)
(N/D)
Este ejemplo es de una configuración típica, con un Node que aloja ZPLS en la misma IP más dos servicios adicionales en IPs separadas. Reemplace “company.com” por 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 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 resoluble por sus servidores DNS externos (puede restringirse para que solo resuelva para los 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.
Última actualización
¿Te fue útil?