Överväganden vid distribution av Zoom Node

läs mer om hur olika distributionsscenarier stöder Zoom Node och Zoom Node Service Modules

Det här avsnittet innehåller flera exempel på hur Zoom Node kan stödja olika Service Modules, som Zoom Meetings Hybrid och Zoom Phone Local Survivability (ZPLS). Typiska implementationer med en dedikerad IP-adress kan se ut som följande samling diagram.

Varje tjänst som distribueras på Zoom Node kräver en unik IP-adress. En Zoom Node kan ha upp till fem (5) IP-adresser tilldelade om noden har tilldelats en specifik adress för hantering och en för varje distribuerad tjänst (upp till fyra) på noden. En Zoom Node som kör en enda tjänst (till exempel ZPLS) kan distribueras med en enda IP-adress om noden och tjänsten tilldelas att dela samma IP-adress.

Flera distributionsalternativ visas nedan. Observera antalet IP-adresser och certifikat (CN/SAN:er) för de olika distributionsalternativen.

Alternativ 1: Zoom Meetings Hybrid distribuerat med dedikerade IP-adresser och värdnamn

Bilden ovan sammanfattar kraven för IP- och certifikatkonfiguration vid distribution av Zoom Meetings Hybrid i lokala eller hybrida molnmiljöer.

Tabellen nedan bryter ned den exempelnod som visas och inkluderar dess aktiv proxy och MMR Service Modules:

Komponent	Värdnamn	TLS-certifikatroll	Funktion
Node operativsystem	node1.customer.com	Common Name (CN)	Kärnorkestrering
Zoom anslutningsprogram Proxy	zcp1.customer.com	Subject Alternative Name (SAN)	Signalering och sessionskontroll
Media Module Router 1	mmr1.customer.com	Subject Alternative Name (SAN)	Mediedirigering och bearbetning
Media Module Router 2	mmr2.customer.com	Subject Alternative Name (SAN)	Mediedirigering och bearbetning
Media Module Router 3	mmr3.customer.com	Subject Alternative Name (SAN)	Mediedirigering och bearbetning

Du måste tilldela varje modul en dedikerad statisk IP-adress. Totalt antal IP-adresser som krävs: fem (5)

Bilden ovan beskriver den minimala konfiguration som behövs för att distribuera Zoom Phone lokal överlevnadsförmåga (ZPLS). ZPLS möjliggör fortsatt tillgänglighet för telefontjänsten vid internet- eller molnavbrott genom att köra överlevnadslogik lokalt på en Zoom Node VM.

Följande värdnamn måste konfigureras i DNS och ingå i TLS-certifikatet:

• node1.customer.com

• zplsl.customer.com

Funktionsmappning av värdnamn

Komponent	Värdnamn	TLS-certifikatroll	Funktion
Node operativsystem	node1.customer.com	Common Name (CN)	Kärnorkestrering
ZPLS-modul	zplsl.customer.com	Subject Alternative Name	Zoom Phone Local Survivability-logik

Konfiguration av TLS-certifikat

Fält	Värde
Common Name (CN)	node1.customer.com
Subject Alternative Names	zplsl.customer.com

Certifikat måste genereras eller anskaffas (publik eller privat CA) så att både CN och SAN:er som listas ovan ingår. Detta möjliggör korrekt TLS-validering för säker kommunikation mellan moduler.

Krav på IP-adress

Mätvärde	Värde / Beskrivning
Totalt antal IP-adresser som krävs	5 (allmän allokering)
Används i ZPLS-kontext	2 IP-adresser (1 för Node operativsystem, 1 för ZPLS-modul)

Även om fem (5) IP-adresser krävs för allmän distribution, används endast två (2) IP-adresser aktivt i ZPLS-distributionen: en per modul, som körs på en dedikerad Node VM.

ZPLS tillåter endast en modul per Node VM. Du kan inte samlokalisera ZPLS med andra Zoom-moduler på samma VM.

Hur jämförs dessa diagram? Den första bilden visar ett exempel på en Zoom Meetings Hybrid-distribution. Den andra bilden visar ett exempel på en Zoom Phone Local Survivability-distribution.

Du kan dela den första IP-adressen/värdnamnet mellan operativsystemet och den första modulen, om så önskas, för att minska antalet IP-adresser, värdnamn och Subject Alternative Names (SANs) som krävs.

Alternativ 2: Zoom Meetings Hybrid distribuerad med en delad IP-adress och ett delat värdnamn

Den här konfigurationen upprepar Node-strukturen som i Zoom Meetings Hybrid-diagrammet i alternativ 1. Men i denna distribution är Node operativsystem delar sin IP-adress med den första distribuerade modulen (vanligtvis Zoom anslutningsprogram Proxy, ZCP). Detta leder till minskad IP-användning samtidigt som TLS- och funktionskraven upprätthålls.

Följande värdnamn måste konfigureras i DNS och ingå i TLS-certifikatet:

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

Funktionsmappning av värdnamn

Komponent	Värdnamn	TLS-certifikatroll	Funktion
ZCP (Zoom anslutningsprogram Proxy)	zcp1.customer.com	Common Name (CN)	Signalering och sessionskontroll
Media Module Router 1	mmr1.customer.com	Subject Alternative Name (SAN)	Mediedirigering och bearbetning
Media Module Router 2	mmr2.customer.com	Subject Alternative Name (SAN)	Mediedirigering och bearbetning
Media Module Router 3	mmr3.customer.com	Subject Alternative Name (SAN)	Mediedirigering och bearbetning

Konfiguration av TLS-certifikat

Fält	Värde
Common Name (CN)	zcp1.customer.com
Subject Alternative Names	mmr1.customer.com, mmr2.customer.com, mmr3.customer.com

Certifikat måste inkludera alla SANs för att stödja säker TLS-kommunikation mellan Zoom Node och de installerade Zoom-modulerna.

Krav på IP-adress

Mätvärde	Värde / Beskrivning
Totalt antal IP-adresser som krävs	4
Strategi för IP-delning	Nodens operativsystem delar IP med den första modulen (ZCP)
Individuella IP-adresser krävs för	ZCP/MMR1, MMR2, MMR3

När IP-adressen är delad mellan nodens operativsystem och den först distribuerade modulen (ZCP), endast fyra (4) IP-adresser krävs. Denna design optimerar användningen av IP samtidigt som den fortfarande uppfyller distributionsstandarderna.

Bilden ovan visar en minimal ZPLS-distribution där Node operativsystem delar sin IP-adress med den installerade ZPLS-modulen. Detta är det enda scenariot i Zoom Node-ramverket där ett TLS-certifikat för en enda värd är giltigt.

Följande värdnamn måste konfigureras i DNS och ingå i TLS-certifikatet:

• zplsl.customer.com

Funktionsmappning av värdnamn

Komponent	Värdnamn	TLS-certifikatroll	Funktion
ZPLS-modul	zplsl.customer.com	Common Name (CN)	Zoom Phone Local Survivability-logik

Konfiguration av TLS-certifikat

Fält	Värde
Common Name (CN)	zcp1.customer.com
SAN:er	(inte krävs)

I denna konfiguration är ett certifikat för en enda värd tillräckligt eftersom både operativsystemet och ZPLS-modulen delar samma värdnamn och IP-adress.

Krav på IP-adress

Mätvärde	Värde / Beskrivning
Totalt antal IP-adresser som krävs	1
Strategi för IP-delning	Nodens operativsystem och ZPLS delar en enda IP-adress
Driftsättningsbegränsning	Endast en modul tillåten per Node VM (endast ZPLS)

ZPLS är det enda scenariot som stöds i Zoom Node-arkitekturen där:

• Ett certifikat för en enda värd (endast CN) är godtagbart

• Endast en (1 )IP-adress krävs för driftsättning på grund av IP-delning mellan operativsystem och modul

• Samlokalisering av ytterligare moduler på samma VM stöds inte

Bestäm vilken metod för certifikathantering som fungerar bäst för dina driftsättningar

Varje tjänstemodul som driftsätts på Zoom Node kräver ett giltigt certifikat signerat av en offentligt betrodd certifikatutfärdare (CA) från Zoom Nodes lista över betrodda certifikat. Detta inkluderar välkända offentliga utfärdare.

Zoom Node erbjuder två metoder för certifikathantering:

• Automatisk PKI: Denna innovativa lösning automatiserar säker certifikatregistrering och förnyelse med offentligt betrodda certifikatutfärdare (CA:er). Zoom står för kostnaderna för registrering och förnyelse.

• Ta med ditt eget certifikat (BYOC): Med det här alternativet tillhandahåller du dina egna certifikat, signerade av valfri större offentligt betrodd CA. Du hanterar certifikatregistrering och förnyelser. Ytterligare överväganden gäller beträffande Zoom Node:s potentiella stöd för upp till fem värdnamn/SAN:er när kundtillhandahållna certifikat används, vilket beskrivs närmare nedan.

Automatisk certifikathantering med Automatisk PKI

Zoom Automatisk PKI installerar giltiga offentligt betrodda CA-certifikat automatiskt för Zoom Node-plattformen, liksom för alla moduler som distribueras på den. Certifikatförnyelse hanteras också automatiskt. Detta förenklar certifikathanteringen för alla tjänster och själva Zoom Node.

Förstå registrering och förnyelse av certifikat med Automatisk PKI

Följande scenario kan hjälpa dig att förstå hur certifikatregistrering och förnyelse fungerar.

Till exempel: En administratör har distribuerat en ny nodinstans. Varje instans kräver ett giltigt x509-certifikat. Certifikatets privata nyckel får aldrig lämna denna instans.

Auto PKI-processen utför följande steg:

1. Hämtning av mallar: Hämtar alla konfigurationsmallar som stöds, inklusive alternativ för flera CA-leverantörer, från Auto PKI-tjänsten i Zoom-moln.

2. Insamling av IP-adresser: Samlar in alla IP-adresser som används av tjänster som körs på noden och skickar dem till Auto PKI-tjänsten i Zoom-moln.

3. Provisionering av DNS-namn: Auto PKI-molntjänsten returnerar en uppsättning DNS-namn i formatet <instance_identifierare>.<customer_identifierare>.zoomonprem.com. Dessa domäner är konfigurerade med A/AAAA-poster.

4. Begäran om reserverat DNS-namn: Begär ett reserverat DNS-namn i formatet rsvd-<randomized_string>.<customer_identifierare>.zoomonprem.com.

5. Generering av certifikatbegäran: Genererar en x509-certifikatbegäran, med DNS-namnen från det tredje steget i SAN-fältet och det reserverade namnet från det fjärde steget i fältet Common Name (CN).

6. Utfärdande av certifikat: Skickar certifikatssigneringsbegäran (CSR) till Auto PKI-tjänsten i Zoom-moln. Denna tjänst arbetar sedan med CA-leverantörer för att utfärda certifikatet, som inkluderar SAN-listan och CN-fältet från föregående steg.

7. Lokal lagring: Skriver det nyligen utfärdade x509-certifikatet från föregående steg och dess tillhörande privata nyckel (genererad tidigare) till lokalt lagringsutrymme, vilket gör dem tillgänglig för tjänster som körs på Node-instansen.

Auto PKI förenklar certifikathanteringen på Zoom Node genom att automatiskt övervaka utgångsdatum och begära nya certifikat, vilket eliminerar behovet av manuell förnyelse.

Ta med dina egna certifikat (BYOC)

Du kan installera dina egna giltiga, offentligt signerade certifikat på Zoom Node med hjälp av det lokala webbgränssnittet. Du kan göra detta antingen under den första installationen eller vid en senare tidpunkt. Processen kommer att vara bekant för dem som är vana vid att installera certifikat i webbaserade applikationer.

Om du väljer att använda dina egna certifikat, kom ihåg att certifikatet kommer att finnas på en server som kommunicerar med flera värdnamn. Därför måste den certifikattyp du väljer ha stöd för kryptering för trafik som kommer från mer än ett värdnamn (certifikatets CN). Alla värdnamn som används för Node och alla distribuerade tjänster måste kunna lösas upp offentligt av Zooms molntjänster.

Zoom rekommenderar två typer av certifikat:

• Wildcard-certifikat

• Multi-SAN-certifikat (även känt som Multi-Domain-certifikat, SAN-certifikat eller UCC-certifikat)

Ett typiskt certifikat för en enda värd fungerar inte med Zoom Node, förutom i det specifika scenariot där en enda IP-adress och ett värdnamn delas mellan Zoom Node och en enda modul. För ytterligare sammanhang, se ZPLS-diagrammet i Överväganden vid distribution av Zoom Node .

Wildcard-certifikat: Rekommenderas för enkelhet

Ett wildcard-certifikat kan kryptera trafik från vilket värdnamn som helst i domänen. Till exempel: Ett wildcard-certifikat som *.customer.com kan kryptera trafik från host1.customer.com och host2.customer.com eller vilket namn som helst inom .customer.com.

När du distribuerar Zoom Node och installerar wildcard-certifikatet kommer det automatiskt att kryptera trafik för alla tjänster du distribuerar på noden, under förutsättning att alla distribuerade tjänster använder ett fullständigt domännamn (FQDN) från wildcard-domänen.

Detta minimerar arbetet med att distribuera tjänster på noden: du behöver inte känna till tjänsternas namn innan du distribuerar dem. Du behöver dock känna till tjänsternas namn om du använder metoden med Multi-SAN-certifikat.

Multi-SAN, Multi-Domain, SAN eller UCC-certifikat

Du måste känna till värdnamnen och IP-adresserna som du kommer att använda för noden (upp till ett [1]) och alla tjänster som du kommer att installera (upp till fyra [4]).

Denna information krävs innan du registrerar ett certifikat.

Ett Multi-SAN-certifikat är nödvändigt för Zoom Node eftersom det krypterar trafik från fem (5) värdnamn. En engångsbegäran för detta certifikat kräver förhandskännedom om all nödvändig information, inklusive planerade nodnamn och namnen på alla tjänster som ska distribueras på noden. Till exempel, med en modul som ZPLS, distribueras endast en ZPLS-modul per nod, så endast ett ytterligare SAN behövs för ZPLS-tjänstens värdnamn.

Följande tabell kan användas som ett exempel:

Värdnamn (SAN)	IP-adress
zoom-node01.company.com	10.1.50.100
zpls.company.com	10.1.50.100
zoom-recording.company.com	10.1.50.101
zoom-webbinarium.company.com	10.1.50.102
(Tjänst 4 - används inte i detta exempel)	(ej tillämpligt)

Detta exempel visar en typisk konfiguration, med en Node som värd för ZPLS på samma IP samt två ytterligare tjänster på separata IP-adresser. Ersätt “company.com” med din faktiska domän och använd din näts IP-adresser.

Krav för DNS-upplösning

Zoom kräver att värdnamnen kan lösas publikt så att ett ömsesidigt förtroende kan upprättas. Alla värdnamn för Zoom Node och alla tjänstvärdnamn som distribueras på Noderna måste ingå i DNS-zonen.

Om din organisation kör separata interna och externa DNS-tjänster eller domäner, måste värdnamnen för Zoom Node vara värdbelagda i en zon som kan lösas upp av dina externa DNS-servrar (kan begränsas till att endast lösas upp för Zoom IP-intervall). Dina interna Zoom-användare och Zoom-moln måste kommunicera med hjälp av samma uppsättning värdnamn.