Considérations relatives au déploiement de Zoom Node
En savoir plus sur la manière 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 comme 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 schémas suivante.
Chaque service déployé sur Zoom Node nécessite une adresse IP unique. Un Zoom Node disposera d’au plus cinq (5) adresses IP qui lui sont attribuées si le Node s’est vu attribuer une adresse spécifique pour la gestion et 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’adresses IP et de certificats (CN/SAN) pour les différentes options de déploiement.
Option 1 : Zoom Meetings Hybrid déployé avec des adresses IP dédiées et des noms d’hôte
L’image ci-dessus résume les exigences de configuration des adresses IP et des certificats pour le déploiement de Zoom Meetings Hybrid dans des environnements sur site ou de cloud hybride.
Le tableau ci-dessous détaille le Node d’exemple et inclut son proxy actif et ses modules de service MMR :
SYSTÈME D'EXPLOITATION du Node
node1.customer.com
Nom commun (CN)
Orchestration principale
Proxy du Connecteur Zoom
zcp1.customer.com
Nom alternatif du sujet (SAN)
Signalisation et contrôle de session
Routeur de module média 1
mmr1.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Routeur de module média 2
mmr2.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Routeur de module média 3
mmr3.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
L’image ci-dessus présente la configuration minimale requise pour déployer Résilience locale de Zoom Phone (ZPLS). ZPLS permet de maintenir la disponibilité du service téléphonique en cas d’interruption d’Internet ou du cloud en exécutant localement la logique de survivabilité sur une machine virtuelle 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
Mappage fonctionnel des noms d’hôte
SYSTÈME D'EXPLOITATION du Node
node1.customer.com
Nom commun (CN)
Orchestration principale
Module ZPLS
zplsl.customer.com
Nom alternatif du sujet
logique de survivabilité locale de Zoom Phone
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 (AC publique ou privée) afin d’inclure à la fois le CN et les SAN répertoriés ci-dessus. Cela permet une validation TLS appropriée pour une communication sécurisée entre modules.
Exigences relatives aux adresses IP
Nombre total d’adresses IP requises
5 (allocation générale)
Utilisé dans le contexte ZPLS
2 adresses IP (1 pour le SYSTÈME D'EXPLOITATION du Node, 1 pour le module ZPLS)
Bien que cinq (5) adresses IP soient requises pour le déploiement général, seules deux (2) adresses IP sont effectivement utilisées dans le déploiement ZPLS : une par module, exécutée sur une machine virtuelle Node dédiée.
ZPLS n’autorise qu’un seul module par machine virtuelle Node. Vous ne pouvez pas co-localiser ZPLS avec d’autres modules Zoom sur la même VM.
En quoi ces schémas diffèrent-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 adresse IP/nom d’hôte entre le SYSTÈME D'EXPLOITATION et le premier module, si vous le souhaitez, afin de 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 adresse IP partagée et un nom d’hôte partagé
Cette configuration reprend la structure du Node telle qu’elle apparaît dans le schéma Zoom Meetings Hybrid de l’option 1. Cependant, dans ce déploiement, le SYSTÈME D'EXPLOITATION du Node partage son adresse IP avec le premier module déployé (généralement le Proxy du Connecteur Zoom, ZCP). Cela réduit l’utilisation des adresses IP tout en respectant 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
Mappage fonctionnel des noms d’hôte
ZCP (Proxy du Connecteur Zoom)
zcp1.customer.com
Nom commun (CN)
Signalisation et contrôle de session
Routeur de module média 1
mmr1.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Routeur de module média 2
mmr2.customer.com
Nom alternatif du sujet (SAN)
Routage et traitement des médias
Routeur de module média 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 SAN pour prendre en charge une communication TLS sécurisée entre Zoom Node et les modules Zoom installés.
Exigences relatives aux adresses IP
Nombre total d’adresses IP requises
4
Stratégie de partage des adresses IP
SYSTÈME D'EXPLOITATION du Node partage l’adresse IP avec le premier module (ZCP)
Adresses IP individuelles requises pour
ZCP/MMR1, MMR2, MMR3
L’image ci-dessus montre un déploiement ZPLS minimal dans lequel le SYSTÈME D'EXPLOITATION du Node partage son adresse IP avec le module ZPLS installé. C’est le seul scénario dans le cadre Zoom Node où un certificat TLS à hôte unique est valide.
Le nom d’hôte suivant doit être configuré dans le DNS et inclus dans le certificat TLS :
zplsl.customer.com
Mappage fonctionnel des noms d’hôte
Module ZPLS
zplsl.customer.com
Nom commun (CN)
logique de survivabilité locale de Zoom Phone
Configuration du certificat TLS
Nom commun (CN)
zcp1.customer.com
SAN
(non requis)
Dans cette configuration, un certificat à hôte unique suffit, car le système d’exploitation et le module ZPLS partagent le même nom d’hôte et la même adresse IP.
Exigences relatives aux adresses IP
Nombre total d’adresses IP requises
1
Stratégie de partage des adresses IP
Le SYSTÈME D'EXPLOITATION du Node et ZPLS partagent une seule adresse IP
Contrainte de déploiement
Un seul module autorisé par machine virtuelle Node (ZPLS uniquement)
ZPLS est le seul scénario pris en charge dans l’architecture Zoom Node où :
Un certificat à hôte unique (CN uniquement) est acceptable
Une seule adresse IP (1) est requise pour le déploiement en raison du partage d’adresse IP entre le système d’exploitation et le module
La co-localisation de modules supplémentaires sur la même VM n’est pas prise en charge
Choisissez 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 (AC) de confiance publique 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’inscription sécurisée des certificats et leur renouvellement auprès d’autorités de certification (AC) de confiance publique. Zoom prend en charge les coûts associés à l’inscription et au renouvellement.
Apportez votre propre certificat (BYOC): Avec cette option, vous fournissez vos propres certificats, signés par n’importe quelle grande AC de confiance publique. Vous gérez l’inscription des certificats et les renouvellements. Des considérations supplémentaires s’appliquent concernant la possibilité pour Zoom Node d’utiliser jusqu’à cinq noms d’hôte/SAN lorsque des certificats fournis par le client sont utilisés, comme détaillé plus loin ci-dessous.
Gestion automatique des certificats avec Auto PKI
Zoom Auto PKI installe automatiquement des certificats CA valides de confiance publique pour la plateforme Zoom Node, ainsi que pour tous les modules déployés dessus. Le renouvellement des certificats est également géré automatiquement. Cela simplifie la gestion des certificats pour tous les services et pour Zoom Node lui-même.
Comprendre l’inscription et le renouvellement des certificats Auto PKI
Le scénario suivant peut vous aider à comprendre comment fonctionnent l’inscription 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 effectue les étapes suivantes :
Récupération du modèle: Récupère tous les modèles de configuration pris en charge, y compris les options pour plusieurs fournisseurs d’AC, depuis le service Auto PKI dans le cloud Zoom.
Collecte des adresses IP: Regroupe 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.
Provisionnement des noms DNS: Le service cloud Auto PKI renvoie un ensemble de noms DNS au format
<identificateur_instance>.<identificateur_client>.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-<chaîne_aléatoire>.<identificateur_client>.zoomonprem.com.Génération de la demande de certificat: Génère une demande de certificat x509, 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 d’AC pour délivrer le certificat, qui inclut la liste SAN et le champ CN de l’étape précédente.
Stockage local: Écrit dans le stockage local le certificat x509 nouvellement délivré de l’étape précédente et sa clé privée correspondante (générée plus tôt), les rendant disponibles pour les services exécutés sur l’instance de Node.
Auto PKI simplifie la gestion des certificats sur Zoom Node en surveillant automatiquement les dates d’expiration et en demandant de nouveaux certificats, ce qui élimine le besoin d’un renouvellement manuel.
Apportez vos propres certificats (BYOC)
Vous pouvez installer vos propres certificats valides, signés publiquement, sur Zoom Node à l’aide de l’interface Web locale. Vous pouvez le faire lors de l’installation initiale ou 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, n’oubliez pas 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 du certificat). Tous les noms d’hôte utilisés pour le Node et tous 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 appelé certificat multi-domaine, certificat SAN ou certificat UCC)
Un certificat typique à hôte unique ne fonctionnera pas avec Zoom Node, sauf dans 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 plus de contexte, consultez le schéma ZPLS dans le Considérations relatives au déploiement de Zoom Node section.
Certificats wildcard : recommandés pour leur simplicité
Un certificat wildcard peut chiffrer le trafic provenant de n’importe quel nom d’hôte du domaine. Par exemple : un certificat wildcard comme *.customer.com peut chiffrer le trafic provenant de host1.customer.com et host2.customer.com ou de n’importe quel nom dans .customer.com.
Lorsque vous déployez Zoom Node et installez le certificat wildcard, il chiffrera automatiquement le trafic de tous les services que vous déployez sur le Node, à condition que tous les services déployés utilisent un nom de domaine pleinement qualifié (FQDN) provenant du domaine wildcard.
Cela minimise l’effort nécessaire 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. En revanche, vous devez connaître les noms des services si vous utilisez la méthode du certificat multi-SAN.
Certificats Multi-SAN, multi-domaine, 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 tout service que vous installerez (jusqu’à quatre [4]).
Ces informations sont requises avant l’inscription d’un certificat.
Un certificat Multi-SAN est nécessaire pour Zoom Node car il chiffre le trafic provenant de cinq (5) noms d’hôte. Une demande unique pour ce certificat nécessite de connaître à l’avance toutes les informations nécessaires, y compris les noms de Node prévus et les noms de tous les services destinés à ê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 supplémentaire est nécessaire pour le nom d’hôte du service ZPLS.
Le tableau suivant peut servir d’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-webinaire.company.com
10.1.50.102
(Service 4 - non utilisé dans cet exemple)
(sans objet)
Cet exemple présente une configuration typique, avec un Node hébergeant ZPLS sur la même adresse IP et deux services supplémentaires sur des adresses 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ésolvables publiquement afin qu’une confiance mutuelle puisse être établie. Tous les noms d’hôte 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 utilise des services ou des domaines DNS internes et externes distincts, les noms d’hôte Zoom Node doivent être hébergés dans une zone résolvable par vos serveurs DNS externes (et la résolution peut être limitée aux plages d’adresses 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 ?