Ü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 die folgende Sammlung von Diagrammen aussehen.

Jeder auf Zoom Node bereitgestellte Dienst erfordert eine eindeutige IP-Adresse. Ein Zoom Node verfügt über bis zu fünf (5) IP-Adressen, die ihm zugewiesen sind, wenn dem Node eine bestimmte Adresse für die Verwaltung und eine für jeden bereitgestellten Dienst (bis zu vier) auf dem Node zugewiesen wurde. Ein Zoom Node, der einen einzelnen Dienst (z. B. ZPLS) ausführt, kann mit einer einzigen IP-Adresse bereitgestellt werden, wenn Node und Dienst so zugewiesen sind, dass sie dieselbe IP-Adresse gemeinsam nutzen.

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

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

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

Die folgende Tabelle zerlegt den Beispiel-Node und umfasst seine aktiven Proxy- und MMR-Service-Module:

Komponente	Hostname	Rolle des TLS-Zertifikats	Funktion
Node-Betriebssystem	node1.customer.com	Allgemeiner Name (CN)	Kern-Orchestrierung
Zoom Connector Proxy	zcp1.customer.com	Alternativer Zertifikatsname (SAN)	Signalisierung und Sitzungssteuerung
Media Module Router 1	mmr1.customer.com	Alternativer Zertifikatsname (SAN)	Medienweiterleitung und -verarbeitung
Media Module Router 2	mmr2.customer.com	Alternativer Zertifikatsname (SAN)	Medienweiterleitung und -verarbeitung
Media Module Router 3	mmr3.customer.com	Alternativer Zertifikatsname (SAN)	Medienweiterleitung und -verarbeitung

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

Das obige Bild umreißt die Mindestkonfiguration, die für die Bereitstellung von Lokale Ausfallsicherheit für Zoom Phone (ZPLS). ZPLS ermöglicht die fortgesetzte Verfügbarkeit des Telefondienstes im Falle eines Internet- oder Cloud-Events, indem die Ausfallsicherungslogik 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

Hostname-Funktionszuordnung

Komponente	Hostname	Rolle des TLS-Zertifikats	Funktion
Node-Betriebssystem	node1.customer.com	Allgemeiner Name (CN)	Kern-Orchestrierung
ZPLS-Modul	zplsl.customer.com	Alternativer Zertifikatsname	Logik für Zoom Phone Local Survivability

TLS-Zertifikatskonfiguration

Feld	Wert
Allgemeiner Name (CN)	node1.customer.com
Alternative Zertifikatsnamen	zplsl.customer.com

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

Anforderungen an IP-Adressen

Metrik	Wert / Beschreibung
Insgesamt erforderliche IP-Adressen	5 (allgemeine Zuweisung)
Verwendet im ZPLS-Kontext	2 IP-Adressen (1 für Node-Betriebssystem, 1 für ZPLS-Modul)

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

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

Wie vergleichen sich diese Diagramme? Das erste Bild zeigt ein Beispiel einer Zoom Meetings-Hybridbereitstellung. Das zweite Bild zeigt ein Beispiel einer Zoom Phone Local Survivability-Bereitstellung.

Sie können die erste IP-Adresse/den ersten Hostnamen zwischen dem Betriebssystem und dem ersten Modul, falls gewünscht, gemeinsam verwenden, um die Anzahl der erforderlichen IP-Adressen, Hostnamen und Subject Alternative Names (SANs) zu reduzieren.

Option 2: Zoom Meetings Hybrid mit gemeinsamer IP-Adresse und gemeinsamem Hostnamen bereitgestellt

Diese Konfiguration wiederholt die Node-Struktur, wie sie im Diagramm für Option 1 der Zoom Meetings Hybrid-Bereitstellung zu sehen ist. In dieser Bereitstellung jedoch Das Node-Betriebssystem teilt seine IP-Adresse mit dem zuerst bereitgestellten Modul (in der Regel der Zoom Connector Proxy, ZCP). Dies führt zu einer geringeren IP-Nutzung bei gleichzeitiger Einhaltung der TLS- und Funktionsanforderungen.

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

Hostname-Funktionszuordnung

Komponente	Hostname	Rolle des TLS-Zertifikats	Funktion
ZCP (Zoom Connector Proxy)	zcp1.customer.com	Allgemeiner Name (CN)	Signalisierung und Sitzungssteuerung
Media Module Router 1	mmr1.customer.com	Alternativer Zertifikatsname (SAN)	Medienweiterleitung und -verarbeitung
Media Module Router 2	mmr2.customer.com	Alternativer Zertifikatsname (SAN)	Medienweiterleitung und -verarbeitung
Media Module Router 3	mmr3.customer.com	Alternativer Zertifikatsname (SAN)	Medienweiterleitung und -verarbeitung

TLS-Zertifikatskonfiguration

Feld	Wert
Allgemeiner Name (CN)	zcp1.customer.com
Alternative Zertifikatsnamen	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
Insgesamt erforderliche IP-Adressen	4
Strategie zur IP-Freigabe	Node-Betriebssystem teilt seine IP-Adresse mit dem ersten Modul (ZCP)
Erforderliche einzelne IPs für	ZCP/MMR1, MMR2, MMR3

Wenn die IP-Adresse geteilt zwischen dem Node-Betriebssystem und dem zuerst bereitgestellten Modul (ZCP) geteilt wird, nur vier (4) IP-Adressen erforderlich. Dieses Design optimiert die IP-Nutzung und erfüllt dennoch die 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 die einzige Situation im Zoom Node-Framework, in der ein TLS-Zertifikat für einen einzelnen Host gültig ist.

Der folgende Hostname muss in DNS konfiguriert und in das TLS-Zertifikat aufgenommen werden:

• zplsl.customer.com

Hostname-Funktionszuordnung

Komponente	Hostname	Rolle des TLS-Zertifikats	Funktion
ZPLS-Modul	zplsl.customer.com	Allgemeiner Name (CN)	Logik für Zoom Phone Local Survivability

TLS-Zertifikatskonfiguration

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

In dieser Konfiguration ist ein Zertifikat für einen einzelnen Host ausreichend, da sowohl das Betriebssystem als auch das ZPLS-Modul denselben Hostnamen und dieselbe IP-Adresse verwenden.

Anforderungen an IP-Adressen

Metrik	Wert / Beschreibung
Insgesamt erforderliche IP-Adressen	1
Strategie zur IP-Freigabe	Node-Betriebssystem und ZPLS teilen sich eine einzige IP-Adresse
Bereitstellungsbeschränkung	Pro Node-VM ist nur ein Modul erlaubt (nur ZPLS)

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

• Ein Zertifikat für einen einzelnen Host (nur CN) ist zulässig

• Aufgrund der IP-Freigabe zwischen Betriebssystem und Modul ist für die Bereitstellung nur eine (1) IP-Adresse erforderlich

• Die Co-Lokalisierung zusätzlicher Module auf derselben VM wird nicht unterstützt

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

Jedes auf Zoom Node bereitgestellte Servicemodul benötigt ein gültiges Zertifikat, das von einer öffentlich vertrauenswürdigen Zertifizierungsstelle (CA) aus der Zertifikat-Vertrauensliste von Zoom Node signiert wurde. Dazu gehören bekannte öffentliche Zertifizierungsstellen.

Zoom Node bietet zwei Methoden zur Zertifikatsverwaltung an:

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

• BYOC: Mit dieser Option stellen Sie Ihre eigenen Zertifikate bereit, die von einer großen öffentlich vertrauenswürdigen CA signiert wurden. Sie sind für die Zertifikatsanmeldung und -erneuerung verantwortlich. Bei kundenseitig bereitgestellten Zertifikaten gelten zusätzliche Überlegungen hinsichtlich des Potenzials von Zoom Node für bis zu fünf Hostnamen/SANs, die weiter unten ausführlicher 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. Auch die Zertifikatserneuerung wird automatisch behandelt. Dies vereinfacht die Zertifikatsverwaltung für alle Dienste und für Zoom Node selbst.

Zertifikatsanmeldung und -erneuerung mit Auto PKI verstehen

Das folgende Szenario kann Ihnen helfen zu verstehen, wie die Zertifikatsanmeldung 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, einschließlich Optionen für mehrere CA-Anbieter, vom Auto-PKI-Dienst in der Zoom Cloud ab.

2. Sammlung von IP-Adressen: Erfasst alle von Diensten verwendeten IP-Adressen, die auf dem Node ausgeführt werden, und sendet sie an den Auto-PKI-Dienst in der Zoom Cloud.

3. Bereitstellung von DNS-Namen: Der Auto-PKI-Cloud-Dienst gibt einen Satz von DNS-Namen im folgenden Format zurück <instance_Kennung>.<customer_Kennung>.zoomonprem.com. Diese Domänen werden mit A/AAAA-Einträgen konfiguriert.

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

5. Generierung einer Zertifikatanforderung: Erstellt eine x509-Zertifikatanforderung und verwendet dabei die DNS-Namen aus dem dritten Schritt im SAN-Feld sowie den reservierten Namen aus dem vierten Schritt im Feld „Common Name“ (CN).

6. Zertifikatausstellung: Sendet die Zertifikatsignierungsanforderung (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 im letzten Schritt neu ausgestellte x509-Zertifikat und den zugehörigen privaten Schlüssel (zuvor generiert) in den lokalen Speicher und macht sie für die auf der Node-Instanz ausgeführten Dienste Verfügbar.

Auto PKI vereinfacht die Zertifikatverwaltung auf Zoom Node, indem es Ablaufdaten automatisch überwacht und neue Zertifikate anfordert, sodass keine manuelle Erneuerung erforderlich ist.

Eigene Zertifikate verwenden (BYOC)

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

Wenn Sie sich für die Verwendung eigener Zertifikate entscheiden, denken Sie daran, dass sich das Zertifikat auf einem Server befindet, der mit mehreren Hostnamen kommuniziert. Daher muss der von Ihnen zu Wählen Zertifikattyp die Verschlüsselung von Datenverkehr unterstützen, der von mehr als einem Hostnamen ausgeht (Zertifikat-CN). Alle für Node und bereitgestellte Dienste verwendeten Hostnamen müssen durch die Cloud-Dienste von Zoom öffentlich auflösbar sein.

Zoom empfiehlt zwei Arten von Zertifikaten:

• Wildcard-Zertifikat

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

Ein typisches Einzel-Host-Zertifikat funktioniert nicht mit Zoom Node, außer in dem speziellen Szenario, in dem eine einzelne IP-Adresse und ein Hostname zwischen Zoom Node und einem einzelnen Modul gemeinsam genutzt werden. Weitere Informationen finden Sie im ZPLS-Diagramm in der Überlegungen zur Bereitstellung von Zoom Node Abschnitt.

Wildcard-Zertifikate: Zur Vereinfachung empfohlen

Ein Wildcard-Zertifikat kann Datenverkehr von jedem Hostnamen in der Domäne verschlüsseln. Beispiel: Ein Wildcard-Zertifikat wie *.customer.com kann Datenverkehr verschlüsseln von host1.customer.com und host2.customer.com oder einem beliebigen 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, vorausgesetzt, dass alle bereitgestellten Dienste einen Fully Qualified Domain Name (FQDN) aus der Wildcard-Domäne verwenden.

Dadurch wird der Aufwand für die Bereitstellung von Diensten auf dem Node minimiert: Sie müssen die Namen der Dienste nicht kennen, bevor Sie sie bereitstellen. Wenn Sie jedoch die Multi-SAN-Zertifikatmethode verwenden, müssen Sie die Dienstnamen kennen.

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 einer [1]) und für alle Dienste verwenden werden, die Sie installieren (bis zu vier [4]).

Diese Informationen sind vor der Beantragung eines Zertifikats erforderlich.

Ein Multi-SAN-Zertifikat ist für Zoom Node erforderlich, da es Datenverkehr von fünf (5) Hostnamen verschlüsselt. Eine einmalige Anforderung für dieses Zertifikat setzt voraus, dass alle notwendigen Informationen im Voraus bekannt sind, einschließlich geplanter Node-Namen und der Namen aller Dienste, die auf dem Node bereitgestellt werden sollen. Bei einem Modul wie ZPLS wird beispielsweise nur ein ZPLS-Modul pro Node bereitgestellt, sodass für den ZPLS-Dienst-Hostnamen nur ein zusätzliches SAN 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
(Dienst 4 – in diesem Beispiel nicht verwendet)	(Nicht zutreffend)

Dieses Beispiel zeigt eine typische Konfiguration, bei der ein Node ZPLS auf derselben IP-Adresse sowie zwei zusätzliche Dienste auf separaten IP-Adressen hostet. Ersetzen Sie „company.com“ durch Ihre tatsächliche Domäne und verwenden Sie die IP-Adressen Ihres Netzwerks.

Anforderungen an die DNS-Auflösung

Zoom erfordert, dass die Hostnamen öffentlich auflösbar sind, damit gegenseitiges Vertrauen hergestellt werden kann. Alle Zoom-Node-Hostnamen und alle auf den Nodes bereitgestellten Dienst-Hostnamen müssen in der DNS-Zone enthalten sein.

Wenn Ihr Unternehmen separate interne und externe DNS-Dienste oder Domains betreibt, müssen die Hostnamen von Zoom Node 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 aufgelöst zu werden). Ihre internen Zoom-Benutzer und die Zoom Cloud müssen mithilfe desselben Satzes von Hostnamen kommunizieren.