Überlegungen zur Bereitstellung von Zoom Node

Erfahren Sie mehr darüber, wie verschiedene Bereitstellungsbeispiele Zoom Node und Zoom Node Service Modules unterstützen

Dieser Abschnitt enthält mehrere Beispiele dafür, wie Zoom Node verschiedene Service-Module wie Zoom Meetings Hybrid und Zoom Phone Local Survivability (ZPLS) unterstützen kann. Typische Bereitstellungen mit einer dedizierten IP-Adresse können wie in der folgenden Sammlung von Diagrammen aussehen.

Jeder auf Zoom Node bereitgestellte Dienst benötigt eine eindeutige IP-Adresse. Ein Zoom Node erhält bis zu fünf (5) IP-Adressen, wenn dem Node eine bestimmte Adresse für das Management zugewiesen wurde und eine für jeden bereitgestellten Dienst (bis zu vier) auf dem Node. Ein Zoom Node, der nur einen Dienst ausführt (z. B. ZPLS), kann mit einer einzigen IP-Adresse bereitgestellt werden, wenn Node und Dienst so zugewiesen sind, dass sie dieselbe IP-Adresse gemeinsam nutzen.

Mehrere Bereitstellungsoptionen sind unten dargestellt. Beachten Sie die Anzahl der IPs und Zertifikate (CN/SANs) für die verschiedenen Bereitstellungsoptionen.

Option 1: Zoom Meetings Hybrid bereitgestellt mit dedizierten IPs und Hostnamen

Das obige Bild fasst die Anforderungen an IP- und Zertifikatkonfiguration für die Bereitstellung zusammen Zoom Meetings Hybrid in lokalen oder hybriden Cloud-Umgebungen.

Die folgende Tabelle gliedert den Beispiel-Node und enthält dessen aktiven Proxy- und MMR-Service-Module:

Komponente	Hostname	TLS-Zertifikatrolle	Funktion
Node-Betriebssystem	node1.customer.com	Common Name (CN)	Kernorchestrierung
Zoom Connector Proxy	zcp1.customer.com	Subject Alternative Name (SAN)	Signalisierung und Sitzungssteuerung
Media Module Router 1	mmr1.customer.com	Subject Alternative Name (SAN)	Mediarouting und -verarbeitung
Media Module Router 2	mmr2.customer.com	Subject Alternative Name (SAN)	Mediarouting und -verarbeitung
Media Module Router 3	mmr3.customer.com	Subject Alternative Name (SAN)	Mediarouting und -verarbeitung

Sie müssen jedem Modul eine dedizierte statische IP-Adresse zuweisen. Insgesamt benötigte IP-Adressen: fünf (5)

Das obige Bild skizziert die Mindestkonfiguration, die erforderlich ist, um bereitzustellen Zoom Phone Local Survivability (ZPLS). ZPLS ermöglicht die fortgesetzte Verfügbarkeit des Telefondienstes im Falle von Internet- oder Cloud-Störungen, indem die Survivability-Logik lokal auf einer Zoom Node-VM ausgeführt wird.

Die folgenden Hostnamen müssen in DNS konfiguriert und im TLS-Zertifikat enthalten sein:

• node1.customer.com

• zplsl.customer.com

Funktionale Zuordnung des Hostnamens

Komponente	Hostname	TLS-Zertifikatrolle	Funktion
Node-Betriebssystem	node1.customer.com	Common Name (CN)	Kernorchestrierung
ZPLS-Modul	zplsl.customer.com	Subject Alternative Name	Zoom Phone Local Survivability-Logik

TLS-Zertifikatkonfiguration

Feld	Wert
Common Name (CN)	node1.customer.com
Subject Alternative Names	zplsl.customer.com

Zertifikate müssen erstellt oder beschafft werden (öffentliche oder private CA), um sowohl den CN als auch die oben aufgeführten SANs einzuschließen. Dies ermöglicht eine ordnungsgemäße TLS-Validierung für sichere Kommunikation zwischen Modulen.

Anforderungen an IP-Adressen

Metrik	Wert / Beschreibung
Gesamt benötigte IP-Adressen	5 (allgemeine Zuweisung)
Verwendet im ZPLS-Kontext	2 IPs (1 für Node-Betriebssystem, 1 für ZPLS-Modul)

Während fünf (5) IPs für die allgemeine Bereitstellung erforderlich sind, werden aktiv nur zwei (2) IP-Adressen verwendet in der ZPLS-Bereitstellung: eine pro Modul, ausgeführt auf einer dedizierten Node-VM.

ZPLS erlaubt nur ein Modul pro Node-VM. Sie können ZPLS nicht zusammen mit anderen Zoom-Modulen auf derselben VM platzieren.

Wie vergleichen sich diese Diagramme? Das erste Bild zeigt ein Beispiel für eine Zoom Meetings Hybrid-Bereitstellung. Das zweite Bild zeigt ein Beispiel für eine Zoom Phone Local Survivability-Bereitstellung.

Sie können die erste IP/den ersten Hostnamen zwischen dem Betriebssystem und dem ersten Modul teilen, wenn gewünscht, um die Anzahl der benötigten IP-Adressen, Hostnamen und Subject Alternative Names (SANs) zu reduzieren.

Option 2: Zoom Meetings Hybrid bereitgestellt mit geteilter IP und gemeinsamem Hostnamen

Diese Konfiguration wiederholt die Node-Struktur wie im Zoom Meetings Hybrid-Diagramm von Option 1. In dieser Bereitstellung teilt jedoch das Node-Betriebssystem seine IP-Adresse mit dem zuerst bereitgestellten Modul (typischerweise dem Zoom Connector Proxy, ZCP). Dies führt zu einer reduzierten IP-Auslastung, während TLS- und Funktionsanforderungen erhalten bleiben.

Die folgenden Hostnamen müssen in DNS konfiguriert und im TLS-Zertifikat enthalten sein:

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

Funktionale Zuordnung des Hostnamens

Komponente	Hostname	TLS-Zertifikatrolle	Funktion
ZCP (Zoom Connector Proxy)	zcp1.customer.com	Common Name (CN)	Signalisierung und Sitzungssteuerung
Media Module Router 1	mmr1.customer.com	Subject Alternative Name (SAN)	Mediarouting und -verarbeitung
Media Module Router 2	mmr2.customer.com	Subject Alternative Name (SAN)	Mediarouting und -verarbeitung
Media Module Router 3	mmr3.customer.com	Subject Alternative Name (SAN)	Mediarouting und -verarbeitung

TLS-Zertifikatkonfiguration

Feld	Wert
Common Name (CN)	zcp1.customer.com
Subject Alternative Names	mmr1.customer.com, mmr2.customer.com, mmr3.customer.com

Zertifikate müssen alle SANs enthalten, um eine sichere TLS-Kommunikation zwischen dem Zoom Node und den installierten Zoom-Modulen zu unterstützen.

Anforderungen an IP-Adressen

Metrik	Wert / Beschreibung
Gesamt benötigte IP-Adressen	4
IP-Sharing-Strategie	Node-Betriebssystem teilt IP mit erstem Modul (ZCP)
Einzelne IPs erforderlich für	ZCP/MMR1, MMR2, MMR3

Wenn die IP-Adresse geteilt zwischen dem Node-Betriebssystem und dem zuerst bereitgestellten Modul (ZCP) wird, sind nur vier (4) IP-Adressen erforderlich. Dieses Design optimiert die IP-Nutzung und entspricht weiterhin den Bereitstellungsstandards.

Das obige Bild zeigt eine minimale ZPLS-Bereitstellung, bei der das Node-Betriebssystem seine IP-Adresse mit dem installierten ZPLS-Modul teilt. Dies ist das einzige Szenario im Zoom Node-Framework, in dem ein Single-Host-TLS-Zertifikat gültig ist.

Der folgende Hostname muss in DNS konfiguriert und im TLS-Zertifikat enthalten sein:

• zplsl.customer.com

Funktionale Zuordnung des Hostnamens

Komponente	Hostname	TLS-Zertifikatrolle	Funktion
ZPLS-Modul	zplsl.customer.com	Common Name (CN)	Zoom Phone Local Survivability-Logik

TLS-Zertifikatkonfiguration

Feld	Wert
Common Name (CN)	zcp1.customer.com
SANs	(nicht erforderlich)

In dieser Konfiguration ist ein Single-Host-Zertifikat ausreichend, da sowohl das Betriebssystem als auch das ZPLS-Modul denselben Hostnamen und dieselbe IP-Adresse teilen.

Anforderungen an IP-Adressen

Metrik	Wert / Beschreibung
Gesamt benötigte IP-Adressen	1
IP-Sharing-Strategie	Node-Betriebssystem und ZPLS teilen eine einzige IP-Adresse
Einschränkung der Bereitstellung	Nur ein Modul pro Node-VM erlaubt (nur ZPLS)

ZPLS ist das einzige unterstützte Szenario in der Zoom Node-Architektur, in dem:

• Ein Single-Host-Zertifikat (nur CN) akzeptabel ist

• Nur eine (1) IP-Adresse aufgrund der OS-Modul-IP-Teilung für die Bereitstellung erforderlich ist

• Die Ko-Lokation zusätzlicher Module auf derselben VM nicht unterstützt wird

Entscheiden Sie, welche Methode zur Zertifikatsverwaltung am besten für Ihre Bereitstellungen geeignet ist

Jedes auf Zoom Node bereitgestellte Service-Modul benötigt ein gültiges Zertifikat, das von einer öffentlich vertrauenswürdigen Zertifizierungsstelle (CA) aus der Zertifikatvertrauensliste von Zoom Node signiert wurde. Dies schließt bekannte öffentliche Stellen mit ein.

Zoom Node bietet zwei Methoden zur Zertifikatsverwaltung an:

• Auto PKI: Diese innovative Lösung automatisiert die sichere Zertifikatsregistrierung und -erneuerung bei öffentlich vertrauenswürdigen Zertifizierungsstellen (CAs). Zoom übernimmt die mit der Registrierung und Erneuerung verbundenen Kosten.

• Bring Your Own Certificate (BYOC): Bei dieser Option stellen Sie Ihre eigenen Zertifikate bereit, die von einer gängigen öffentlich vertrauenswürdigen CA signiert sind. Sie sind für die Zertifikatsregistrierung und -erneuerungen verantwortlich. Zusätzliche Überlegungen gelten hinsichtlich der Möglichkeit, dass Zoom Node bis zu fünf Hostnamen/SANs hat, wenn kundenseitige Zertifikate verwendet werden, die weiter unten näher beschrieben werden.

Automatische Zertifikatsverwaltung mit Auto PKI

Zoom Auto PKI installiert automatisch gültige, öffentlich vertrauenswürdige CA-Zertifikate für die Zoom Node-Plattform sowie für alle darauf bereitgestellten Module. Die Zertifikatsverlängerung wird ebenfalls automatisch gehandhabt. Dies vereinfacht die Zertifikatsverwaltung für alle Dienste und den Zoom Node selbst.

Verstehen der Auto PKI-Zertifikatsregistrierung und -erneuerung

Das folgende Szenario kann Ihnen helfen zu verstehen, wie die Zertifikatsregistrierung und -erneuerung funktioniert.

Zum Beispiel: Ein Administrator hat eine neue Node-Instanz bereitgestellt. Jede Instanz benötigt ein gültiges x509-Zertifikat. Der private Schlüssel des Zertifikats darf diese Instanz niemals verlassen.

Der Auto PKI-Prozess führt die folgenden Schritte aus:

1. Vorlagenabruf: Ruft alle unterstützten Konfigurationsvorlagen ab, einschließlich Optionen für mehrere CA-Anbieter, vom Auto PKI-Dienst in der Zoom-Cloud.

2. Sammeln von IP-Adressen: Erfasst alle von Diensten auf dem Node verwendeten IP-Adressen und sendet diese an den Auto PKI-Dienst in der Zoom-Cloud.

3. Bereitstellung von DNS-Namen: Der Auto PKI-Cloud-Dienst gibt eine Reihe von DNS-Namen im Format zurück <instance_identifier>.<customer_identifier>.zoomonprem.com. Diese Domains werden mit A/AAAA-Einträgen konfiguriert.

4. Anforderung eines reservierten DNS-Namens: Fordert einen reservierten DNS-Namen im Format an rsvd-<randomized_string>.<customer_identifier>.zoomonprem.com.

5. Erzeugung der Zertifikatsanforderung: Generiert eine x509-Zertifikatsanforderung, wobei die DNS-Namen aus dem dritten Schritt im SAN-Feld und der reservierte Name aus dem vierten Schritt im Common Name (CN)-Feld verwendet werden.

6. Zertifikatsausstellung: Sendet die Certificate Signing Request (CSR) an den Auto PKI-Dienst in der Zoom-Cloud. Dieser Dienst arbeitet dann mit CA-Anbietern zusammen, um das Zertifikat auszustellen, das die SAN-Liste und das CN-Feld aus dem vorherigen Schritt enthält.

7. Lokale Speicherung: Schreibt das neu ausgestellte x509-Zertifikat aus dem letzten Schritt und den zugehörigen privaten Schlüssel (zuvor generiert) in den lokalen Speicher und macht sie für auf der Node-Instanz ausgeführte Dienste verfügbar.

Auto PKI vereinfacht die Zertifikatsverwaltung auf Zoom Node, indem es automatisch Ablaufdaten überwacht und neue Zertifikate anfordert, wodurch die Notwendigkeit manueller Erneuerung entfällt.

Bring Your Own Certificates (BYOC)

Sie können Ihre eigenen gültigen, öffentlich signierten Zertifikate auf Zoom Node über die lokale Weboberfläche installieren. Dies ist entweder während der Erstinstallation oder zu einem späteren Zeitpunkt möglich. Der Prozess wird denen vertraut sein, die Zertifikate in webbasierten Anwendungen installieren.

Wenn Sie sich entscheiden, Ihre eigenen Zertifikate zu verwenden, denken Sie daran, dass das Zertifikat auf einem Server vorhanden sein wird, der mit mehreren Hostnamen kommuniziert. Daher muss der von Ihnen gewählte Zertifikatstyp Verschlüsselung für Datenverkehr unterstützen, der von mehr als einem Hostnamen ausgeht (Zertifikat-CN). Alle Hostnamen, die für den Node und alle bereitgestellten Dienste verwendet werden, müssen von den Cloud-Diensten von Zoom öffentlich auflösbar sein.

Zoom empfiehlt zwei Arten von Zertifikaten:

• Wildcard-Zertifikat

• Multi-SAN-Zertifikat (auch bekannt als Multi-Domain-Zertifikat, SAN-Zertifikat oder UCC-Zertifikat)

Ein typisches Single-Host-Zertifikat funktioniert nicht mit Zoom Node, außer in dem spezifischen Szenario, in dem eine einzelne IP-Adresse und ein Hostname zwischen Zoom Node und einem einzelnen Modul geteilt werden. Für zusätzlichen Kontext siehe das ZPLS-Diagramm im Überlegungen zur Bereitstellung von Zoom Node Abschnitt.

Wildcard-Zertifikate: Empfohlen wegen Einfachheit

Ein Wildcard-Zertifikat kann den Datenverkehr von jedem Hostnamen in der Domain verschlüsseln. Zum Beispiel: Ein Wildcard-Zertifikat wie *.customer.com kann den Datenverkehr von host1.customer.com als host2.customer.com oder jedem Namen innerhalb von .customer.com.

Wenn Sie Zoom Node bereitstellen und das Wildcard-Zertifikat installieren, verschlüsselt es automatisch den Datenverkehr für alle Dienste, die Sie auf dem Node bereitstellen, unter der Voraussetzung, dass alle bereitgestellten Services einen Fully Qualified Domain Name (FQDN) aus der Wildcard-Domain verwenden.

Dies minimiert den Aufwand bei der Bereitstellung von Diensten auf dem Node: Sie müssen die Namen der Dienste nicht kennen, bevor Sie sie bereitstellen. Allerdings müssen Sie die Servicenamen kennen, wenn Sie die Multi-SAN-Zertifikat-Methode verwenden.

Multi-SAN-, Multi-Domain-, SAN- oder UCC-Zertifikate

Sie müssen die Hostnamen und IP-Adressen kennen, die Sie für den Node (bis zu einem [1]) und alle Services, die Sie installieren werden (bis zu vier [4]), verwenden werden.

Diese Informationen sind vor der Registrierung eines Zertifikats erforderlich.

Ein Multi-SAN-Zertifikat ist für Zoom Node erforderlich, da es den Datenverkehr von fünf (5) Hostnamen verschlüsselt. Eine einmalige Anfrage für dieses Zertifikat erfordert das vorherige Wissen über alle notwendigen Informationen, einschließlich geplanter Node-Namen und der Namen aller Dienste, die auf dem Node bereitgestellt werden sollen. Beispielsweise wird bei einem Modul wie ZPLS nur ein ZPLS-Modul pro Node bereitgestellt, sodass nur ein zusätzlicher SAN für den ZPLS-Service-Hostname erforderlich ist.

Die folgende Tabelle kann als Beispiel verwendet werden:

Hostname (SAN)	IP-Adresse
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 - in diesem Beispiel nicht verwendet)	(N/A)

Dieses Beispiel zeigt eine typische Konfiguration mit einem Node, der ZPLS auf derselben IP hostet, plus zwei zusätzliche Dienste auf separaten IPs. Ersetzen Sie „company.com“ durch Ihre tatsächliche Domain und verwenden Sie die IP-Adressen Ihres Netzwerks.

Anforderungen an die DNS-Auflösung

Zoom verlangt, dass die Hostnamen öffentlich auflösbar sind, damit eine zweiseitige Vertrauensstellung hergestellt werden kann. Alle Zoom Node-Hostnamen und alle auf den Nodes bereitgestellten Service-Hostnamen müssen in der DNS-Zone enthalten sein.

Wenn Ihre Organisation separate interne und externe DNS-Dienste oder -Domänen betreibt, müssen die Zoom Node-Hostnamen in einer Zone gehostet werden, die von Ihren externen DNS-Servern aufgelöst werden kann (kann darauf beschränkt werden, nur für Zoom-IP-Bereiche aufzulösen). Ihre internen Zoom-Benutzer und die Zoom-Cloud müssen mit derselben Menge an Hostnamen kommunizieren.