Överväganden för driftsättning av Zoom Node

Läs mer om hur olika driftsättningsexempel stöder Zoom Node och Zoom Node Service Modules

Detta avsnitt innehåller flera exempel på hur Zoom Node kan stödja olika tjänstemoduler som Zoom Meetings Hybrid och Zoom Phone Local Survivability (ZPLS). Typiska distributioner 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 tjänst som distribueras (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 har tilldelats att dela samma IP-adress.

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

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

Bilden ovan sammanfattar kraven på IP- och certifikatkonfiguration för att distribuera Zoom Meetings Hybrid i lokala miljöer eller hybrida molnmiljöer.

Tabellen nedan beskriver exempel-noden och inkluderar dess aktiv proxy och MMR-tjänstemoduler:

Komponent	Värdnamn	TLS certifikatroll	Funktion
Node operativsystem	node1.customer.com	Common Name (CN)	Kärnorkestrering
Zoom anslutningsprogramproxy	zcp1.customer.com	Subject Alternative Name (SAN)	Signalering och sessionkontroll
Mediamodulrouter 1	mmr1.customer.com	Subject Alternative Name (SAN)	Dirigering och bearbetning av media
Mediamodulrouter 2	mmr2.customer.com	Subject Alternative Name (SAN)	Dirigering och bearbetning av media
Mediamodulrouter 3	mmr3.customer.com	Subject Alternative Name (SAN)	Dirigering och bearbetning av media

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

Bilden ovan visar den minimikonfiguration som krävs för att distribuera Zoom Phone Lokal överlevnadsförmåga (ZPLS). ZPLS möjliggör fortsatt tillgänglighet för telefontjänsten i händelse av störningar i internet eller moln genom att köra överlevnadslogik lokalt på en Zoom Node VM.

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

• node1.customer.com

• zplsl.customer.com

Funktionell mappning av värdnamn

Komponent	Värdnamn	TLS certifikatroll	Funktion
Node operativsystem	node1.customer.com	Common Name (CN)	Kärnorkestrering
ZPLS-modul	zplsl.customer.com	Alternativt namn för ämne	Zoom Phone Local Survivability-logik

Konfiguration av TLS-certifikat

Fält	Värde
Common Name (CN)	node1.customer.com
Alternativa namn för ämne	zplsl.customer.com

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

Krav på IP-adress

Mått	Värde / Beskrivning
Totalt antal IP-adresser som krävs	5 (allmän tilldelning)
Används i ZPLS-kontext	2 IP-adresser (1 för nodens operativsystem, 1 för ZPLS-modulen)

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

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

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

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 distribuerat med en delad IP-adress och ett delat värdnamn

Den här konfigurationen upprepar Node-strukturen som i diagrammet för Zoom Meetings Hybrid i alternativ 1. Men i den här distributionen, Node-operativsystemet delar sin IP-adress med den först 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 inkluderas i TLS-certifikatet:

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

Funktionell mappning av värdnamn

Komponent	Värdnamn	TLS certifikatroll	Funktion
ZCP (Zoom Anslutningsprogram Proxy)	zcp1.customer.com	Common Name (CN)	Signalering och sessionkontroll
Mediamodulrouter 1	mmr1.customer.com	Subject Alternative Name (SAN)	Dirigering och bearbetning av media
Mediamodulrouter 2	mmr2.customer.com	Subject Alternative Name (SAN)	Dirigering och bearbetning av media
Mediamodulrouter 3	mmr3.customer.com	Subject Alternative Name (SAN)	Dirigering och bearbetning av media

Konfiguration av TLS-certifikat

Fält	Värde
Common Name (CN)	zcp1.customer.com
Alternativa namn för ämne	mmr1.customer.com, mmr2.customer.com, mmr3.customer.com

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

Krav på IP-adress

Mått	Värde / Beskrivning
Totalt antal IP-adresser som krävs	4
Strategi för IP-delning	Operativsystemet på noden delar IP-adress med den första modulen (ZCP)
Individuella IP-adresser krävs för	ZCP/MMR1, MMR2, MMR3

När IP-adressen är delad mellan operativsystemet på noden och den första 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-operativsystemet 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 enskild värd är giltigt.

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

• zplsl.customer.com

Funktionell mappning 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 obligatoriskt)

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

Krav på IP-adress

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

ZPLS är det enda stödda scenariot 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 distribueras på Zoom Node kräver ett giltigt certifikat signerat av en offentligt betrodd certifikatutfärdare (CA) från Zoom Node:s lista över betrodda certifikat. Detta inkluderar välkända offentliga myndigheter.

Zoom Node erbjuder två certifikathanteringsmetoder:

• Automatisk PKI: Denna innovativa lösning automatiserar säker registrering och förnyelse av certifikat med allmänt betrodda certifikatutfärdare (CA:er). Zoom täcker kostnaderna som är kopplade till registrering och förnyelse.

• Ta med ditt eget certifikat (BYOC): Med det här alternativet tillhandahåller du dina egna certifikat, signerade av en valfri större offentligt betrodd CA. Du hanterar certifikatsregistrering och förnyelser. Ytterligare överväganden gäller för 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 Auto PKI

Zoom Auto PKI installerar giltiga, offentligt betrodda CA-certifikat automatiskt för Zoom Node-plattformen, samt 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å automatisk PKI-certifikatregistrering och förnyelse

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 Node-instans. 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. Mallhämtning: Hämtar alla stödda konfigurationsmallar, inklusive alternativ för flera CA-leverantörer, från Auto PKI-tjänsten i Zoom-molnet.

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

3. DNS-namnförsörjning: Auto PKI-molntjänsten returnerar en uppsättning DNS-namn i formatet <instans_identifierare>.<kund_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 Common Name (CN)-fältet.

6. Utfärdande av certifikat: Skickar certifikatsigneringsbegäran (CSR) till Auto PKI-tjänsten i Zoom-moln. Denna tjänst samarbetar sedan med CA-leverantörer för att utfärda certifikatet, vilket 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 det sista steget och dess motsvarande privata nyckel (som genererades tidigare) till lokal lagring, så att de blir tillgängliga för tjänster som körs på Node-instansen.

Auto PKI förenklar hanteringen av certifikat 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 ett senare tillfälle. 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 stödja 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 vara offentligt upplösbara av Zooms molntjänster.

Zoom rekommenderar två typer av certifikat:

• Jokerteckencertifikat

• 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 för driftsättning av Zoom Node avsnittet.

Wildcard-certifikat: Rekommenderas för enkelhet

Ett wildcard-certifikat kan kryptera trafik från valfritt värdnamn 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 krypterar det automatiskt trafik för alla tjänster du distribuerar på noden, med kravet att alla distribuerade tjänster använder ett Fullständigt kvalificerat 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 de värdnamn och IP-adresser som du kommer att använda för Node (upp till en [1]) och alla tjänster som du kommer att installera (upp till fyra [4]).

Denna information krävs innan ett certifikat registreras.

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 Node-namn och namnen på alla tjänster som är planerade för driftsättning på Node. Till exempel, med en modul som ZPLS, driftsätts endast en ZPLS-modul per Node, 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 är en typisk konfiguration, med en Node som är värd för ZPLS på samma IP plus två ytterligare tjänster på separata IP-adresser. Ersätt “company.com” med din faktiska domän och använd ditt nätverks IP-adresser.

Krav på DNS-uppslagning

Zoom kräver att värdnamnen kan slås upp offentligt så att ömsesidigt förtroende i båda riktningar kan upprättas. Alla Zoom Node-värdnamn och alla tjänstvärdnamn som distribueras på Node:arna måste ingå i DNS-zonen.

Om din organisation använder separata interna och externa DNS-tjänster eller domäner, behöver Zoom Node-värdnamnen vara värdar i en zon som kan slås upp av dina externa DNS-servrar (kan begränsas till att endast slå upp för Zoom-IP-intervall). Dina interna Zoom-användare och Zoom-moln behöver kommunicera med samma uppsättning värdnamn.