Considérations de déploiement de Zoom Node
En savoir plus sur la façon dont divers exemples de déploiement prennent en charge Zoom Node et les modules de service Zoom Node
Cette section contient plusieurs exemples de la manière dont Zoom Node peut prendre en charge divers modules de service tels que Zoom Meetings Hybrid et Zoom Phone Local Survivability (ZPLS). Les déploiements typiques avec une adresse IP dédiée peuvent ressembler à la collection de diagrammes suivante.
Chaque service déployé sur Zoom Node nécessite une adresse IP unique. Un Zoom Node se verra attribuer jusqu'à cinq (5) adresses IP s'il dispose d'une adresse spécifique pour la gestion et d'une pour chaque service déployé (jusqu'à quatre) sur le Node. Un Zoom Node exécutant un seul service (comme ZPLS) peut être déployé avec une seule adresse IP si le Node et le service sont configurés pour partager la même adresse IP.
Plusieurs options de déploiement sont présentées ci-dessous. Notez le nombre d'IPs et de certificats (CN/SANs) pour les différentes options de déploiement.
Option 1 : Zoom Meetings Hybrid déployé avec des IPs et des noms d'hôte dédiés
L'image ci-dessus résume les exigences de configuration des IP et des certificats pour le déploiement de Zoom Meetings Hybrid dans des environnements sur site ou en cloud hybride.
Le tableau ci-dessous détaille l'exemple de Node et inclut son proxy actif et les modules de service MMR :
OS du Node
node1.customer.com
Nom commun (CN)
Orchestration centrale
Zoom Connector Proxy
zcp1.customer.com
Nom alternatif du sujet (SAN)
Signalisation et contrôle de session
Media Module Router 1
mmr1.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Media Module Router 2
mmr2.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Media Module Router 3
mmr3.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Vous devez attribuer à chaque module une adresse IP statique dédiée. Nombre total d'adresses IP requises : cinq (5)
L'image ci-dessus décrit la configuration minimale nécessaire pour déployer Zoom Phone Local Survivability (ZPLS). ZPLS permet le maintien de la disponibilité du service téléphonique en cas de perturbation d'Internet ou du cloud en exécutant localement la logique de survivabilité sur une VM Zoom Node.
Les noms d'hôte suivants doivent être configurés dans le DNS et inclus dans le certificat TLS :
node1.customer.comzplsl.customer.com
Cartographie fonctionnelle des noms d'hôte
OS du Node
node1.customer.com
Nom commun (CN)
Orchestration centrale
Module ZPLS
zplsl.customer.com
Nom alternatif du sujet
Logique de Zoom Phone Local Survivability
Configuration du certificat TLS
Nom commun (CN)
node1.customer.com
Noms alternatifs du sujet
zplsl.customer.com
Les certificats doivent être générés ou obtenus (CA publique ou privée) pour inclure à la fois le CN et les SAN listés ci-dessus. Cela permet une validation TLS correcte pour une communication intra-module sécurisée.
Exigences en matière d'adresses IP
Nombre total d'adresses IP requises
5 (allocation générale)
Utilisé dans le contexte ZPLS
2 IP (1 pour l'OS du Node, 1 pour le module ZPLS)
Bien que cinq (5) IP soient requises pour un déploiement général, seules deux (2) adresses IP sont utilisées activement dans le déploiement ZPLS : une par module, exécutée sur une VM Node dédiée.
ZPLS n'autorise qu'un seul module par VM Node. Vous ne pouvez pas co-localiser ZPLS avec d'autres modules Zoom sur la même VM.
En quoi ces diagrammes se comparent-ils ? La première image montre un exemple de déploiement Zoom Meetings Hybrid. La deuxième image montre un exemple de déploiement Zoom Phone Local Survivability.
Vous pouvez partager la première IP/nom d'hôte entre l'OS et le premier module, si vous le souhaitez, pour réduire le nombre d'adresses IP, de noms d'hôte et de Noms alternatifs du sujet (SAN) requis.
Option 2 : Zoom Meetings Hybrid déployé avec une IP partagée et un nom d'hôte partagé
Cette configuration répète la structure du Node comme dans le diagramme Zoom Meetings Hybrid de l'Option 1. Cependant, dans ce déploiement, le OS du Node partage son adresse IP avec le premier module déployé (typiquement le Zoom Connector Proxy, ZCP). Cela réduit l'utilisation des IP tout en maintenant les exigences TLS et fonctionnelles.
Les noms d'hôte suivants doivent être configurés dans le DNS et inclus dans le certificat TLS :
zcp1.customer.commmr1.customer.commmr2.customer.commmr3.customer.com
Cartographie fonctionnelle des noms d'hôte
ZCP (Zoom Connector Proxy)
zcp1.customer.com
Nom commun (CN)
Signalisation et contrôle de session
Media Module Router 1
mmr1.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Media Module Router 2
mmr2.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Media Module Router 3
mmr3.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Configuration du certificat TLS
Nom commun (CN)
zcp1.customer.com
Noms alternatifs du sujet
mmr1.customer.com, mmr2.customer.com, mmr3.customer.com
Les certificats doivent inclure tous les SANs pour permettre une communication TLS sécurisée entre le Zoom Node et les modules Zoom installés.
Exigences en matière d'adresses IP
Nombre total d'adresses IP requises
4
Stratégie de partage d'IP
L'OS du Node partage l'IP avec le premier module (ZCP)
IPs individuelles requises pour
ZCP/MMR1, MMR2, MMR3
Lorsque l'adresse IP est partagée entre l'OS du Node et le premier module déployé (ZCP), seules quatre (4) adresses IP sont requises. Ce design optimise l'utilisation des IP tout en respectant les normes de déploiement.
L'image ci-dessus montre un déploiement ZPLS minimal où le OS du Node partage son adresse IP avec le module ZPLS installé. Il s'agit du seul scénario dans le cadre de l'architecture Zoom Node où un certificat TLS mono-hôte est valide.
Le nom d'hôte suivant doit être configuré dans le DNS et inclus dans le certificat TLS :
zplsl.customer.com
Cartographie fonctionnelle des noms d'hôte
Module ZPLS
zplsl.customer.com
Nom commun (CN)
Logique de Zoom Phone Local Survivability
Configuration du certificat TLS
Nom commun (CN)
zcp1.customer.com
SANs
(non requis)
Dans cette configuration, un certificat mono-hôte est suffisant puisque l'OS et le module ZPLS partagent le même nom d'hôte et la même adresse IP.
Exigences en matière d'adresses IP
Nombre total d'adresses IP requises
1
Stratégie de partage d'IP
L'OS du Node et ZPLS partagent une seule adresse IP
Contraintes de déploiement
Un seul module autorisé par VM Node (ZPLS uniquement)
ZPLS est le seul scénario pris en charge dans l'architecture Zoom Node où :
Un certificat mono-hôte (CN uniquement) est acceptable
Une seule (1) adresse IP est requise pour le déploiement en raison du partage d'IP OS-module
La co-localisation de modules supplémentaires sur la même VM n'est pas prise en charge
Décidez de la méthode de gestion des certificats qui convient le mieux à vos déploiements
Chaque module de service déployé sur Zoom Node nécessite un certificat valide signé par une autorité de certification (CA) publiquement reconnue figurant dans la liste de confiance des certificats de Zoom Node. Cela inclut les autorités publiques bien connues.
Zoom Node propose deux méthodes de gestion des certificats :
Auto PKI: Cette solution innovante automatise l'enregistrement et le renouvellement sécurisés des certificats auprès des autorités de certification (CA) publiquement reconnues. Zoom prend en charge les coûts liés à l'enregistrement et au renouvellement.
Bring Your Own Certificate (BYOC): Avec cette option, vous fournissez vos propres certificats, signés par n'importe quelle grande CA publique reconnue. Vous gérez l'enregistrement et le renouvellement des certificats. Des considérations supplémentaires s'appliquent en ce qui concerne la possibilité pour Zoom Node d'avoir jusqu'à cinq noms d'hôte/SANs lors de l'utilisation de certificats fournis par le client, qui sont détaillées plus loin.
Gestion automatique des certificats avec Auto PKI
Zoom Auto PKI installe automatiquement des certificats CA publiquement reconnus valides pour la plate-forme Zoom Node, ainsi que pour tous les modules qui y sont déployés. Le renouvellement des certificats est également géré automatiquement. Cela simplifie la gestion des certificats pour tous les services et pour le Zoom Node lui-même.
Comprendre l'enregistrement et le renouvellement des certificats Auto PKI
Le scénario suivant peut vous aider à comprendre comment fonctionnent l'enregistrement et le renouvellement des certificats.
Par exemple : un administrateur a déployé une nouvelle instance de Node. Chaque instance nécessite un certificat x509 valide. La clé privée du certificat ne doit jamais quitter cette instance.
Le processus Auto PKI exécute les étapes suivantes :
Récupération des modèles: Récupère tous les modèles de configuration pris en charge, y compris les options pour plusieurs fournisseurs de CA, depuis le service Auto PKI dans le cloud Zoom.
Collecte des adresses IP: Rassemble toutes les adresses IP utilisées par les services exécutés sur le Node et les envoie au service Auto PKI dans le cloud Zoom.
Approvisionnement des noms DNS: Le service cloud Auto PKI renvoie un ensemble de noms DNS au format
<instance_identifier>.<customer_identifier>.zoomonprem.com. Ces domaines sont configurés avec des enregistrements A/AAAA.Demande de nom DNS réservé: Demande un nom DNS réservé au format
rsvd-<randomized_string>.<customer_identifier>.zoomonprem.com.Génération de la demande de certificat: Génère une demande de certificat x509 (CSR), en utilisant les noms DNS de la troisième étape dans le champ SAN et le nom réservé de la quatrième étape dans le champ Nom commun (CN).
Délivrance du certificat: Envoie la demande de signature de certificat (CSR) au service Auto PKI dans le cloud Zoom. Ce service collabore ensuite avec des fournisseurs de CA pour émettre le certificat, qui inclut la liste des SAN et le champ CN de l'étape précédente.
Stockage local: Écrit le certificat x509 nouvellement émis de l'étape précédente et sa clé privée correspondante (générée plus tôt) dans le stockage local, les rendant disponibles pour les services exécutés sur l'instance Node.
Auto PKI simplifie la gestion des certificats sur Zoom Node en surveillant automatiquement les dates d'expiration et en demandant de nouveaux certificats, éliminant ainsi la nécessité de renouvellements manuels.
Bring Your Own Certificates (BYOC)
Vous pouvez installer vos propres certificats valides, signés publiquement, sur Zoom Node en utilisant l'interface web locale. Vous pouvez le faire soit lors de l'installation initiale, soit ultérieurement. Le processus sera familier à ceux qui ont l'habitude d'installer des certificats sur des applications web.
Si vous choisissez d'utiliser vos propres certificats, rappelez-vous que le certificat se trouvera sur un serveur communiquant avec plusieurs noms d'hôte. Par conséquent, le type de certificat que vous choisissez doit prendre en charge le chiffrement du trafic provenant de plus d'un nom d'hôte (CN de certificat). Tous les noms d'hôte utilisés pour le Node et pour les services déployés doivent être résolvables publiquement par les services cloud de Zoom.
Zoom recommande deux types de certificats :
Certificat Wildcard
Certificat Multi-SAN (également connu sous le nom de certificat multi-domaine, certificat SAN ou certificat UCC)
Un certificat mono-hôte typique ne fonctionnera pas avec Zoom Node, sauf pour le scénario spécifique où une seule adresse IP et un seul nom d'hôte sont partagés entre Zoom Node et un seul module. Pour un contexte supplémentaire, voir le diagramme ZPLS dans le Considérations de déploiement de Zoom Node .
Certificats Wildcard : recommandés pour la simplicité
Un certificat wildcard peut chiffrer le trafic depuis n'importe quel nom d'hôte du domaine. Par exemple : un certificat wildcard tel que *.customer.com peut chiffrer le trafic depuis host1.customer.com et host2.customer.com ou tout nom dans .customer.com.
Lorsque vous déployez Zoom Node et installez le certificat wildcard, il chiffrera automatiquement le trafic pour tous les services que vous déployez sur le Node à condition que tous les services déployés utilisent un nom de domaine entièrement qualifié (FQDN) du domaine wildcard.
Cela minimise l'effort pour déployer des services sur le Node : vous n'avez pas besoin de connaître les noms des services avant de les déployer. Cependant, vous devez connaître les noms des services si vous utilisez la méthode de certificat multi-SAN.
Certificats Multi-SAN, Multi-Domain, SAN ou UCC
Vous devez connaître les noms d'hôte et les adresses IP que vous utiliserez pour le Node (jusqu'à un [1]) et pour tous les services que vous installerez (jusqu'à quatre [4]).
Ces informations sont requises avant d'enregistrer un certificat.
Un certificat Multi-SAN est nécessaire pour Zoom Node car il chiffre le trafic depuis cinq (5) noms d'hôte. Une demande unique pour ce certificat nécessite la connaissance préalable de toutes les informations nécessaires, y compris les noms de Node prévus et les noms de tous les services prévus pour être déployés sur le Node. Par exemple, avec un module comme ZPLS, un seul module ZPLS est déployé par Node, donc un seul SAN additionnel est nécessaire pour le nom d'hôte du service ZPLS.
Le tableau suivant peut être utilisé comme exemple :
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
(Service 4 - non utilisé dans cet exemple)
(N/A)
Cet exemple correspond à une configuration typique, avec un Node hébergeant ZPLS sur la même IP plus deux services supplémentaires sur des IP séparées. Remplacez “company.com” par votre domaine réel et utilisez les adresses IP de votre réseau.
Exigences de résolution DNS
Zoom exige que les noms d'hôte soient résolubles publiquement afin qu'une confiance bilatérale puisse être établie. Tous les noms d'hôte du Zoom Node et tous les noms d'hôte des services déployés sur les Nodes doivent être inclus dans la zone DNS.
Si votre organisation gère des services ou des domaines DNS internes et externes séparés, les noms d'hôte Zoom Node doivent être hébergés dans une zone résoluble par vos serveurs DNS externes (peut être restreinte à ne résoudre que pour les plages d'IP Zoom). Vos utilisateurs Zoom internes et le cloud Zoom doivent communiquer en utilisant le même ensemble de noms d'hôte.
Mis à jour
Ce contenu vous a-t-il été utile ?