Overwegingen voor Zoom Node-implementatie

Meer informatie over hoe verschillende implementatievoorbeelden Zoom Node en Zoom Node Service Modules ondersteunen

Deze sectie bevat verschillende voorbeelden van hoe Zoom Node verschillende Service Modules kan ondersteunen, zoals Zoom Meetings Hybrid en Zoom Phone Local Survivability (ZPLS). Typische implementaties met een toegewijd IP-adres kunnen eruitzien als de volgende verzameling diagrammen.

Elke service die op Zoom Node wordt geïmplementeerd, vereist een uniek IP-adres. Een Zoom Node kan maximaal vijf (5) IP-adressen toegewezen krijgen als aan de Node een specifiek adres is toegewezen voor beheer en één voor elke geïmplementeerde service (tot vier) op de Node. Een Zoom Node die één enkele service uitvoert (zoals ZPLS) kan worden geïmplementeerd met één IP-adres als aan de Node en de service is toegewezen om hetzelfde IP-adres te delen.

Hieronder worden verschillende implementatieopties weergegeven. Let op het aantal IP's en certificaaten (CN/SAN's) voor de verschillende implementatieopties.

Optie 1: Zoom Meetings Hybrid geïmplementeerd met toegewezen IP's en hostnamen

De bovenstaande afbeelding vat de vereisten voor IP- en certificaatconfiguratie samen voor het implementeren van Zoom Meetings Hybrid in on-premises of hybride Cloud-omgevingen.

De onderstaande tabel splitst de voorbeeld-Node op en bevat de actieve proxy- en MMR-Service Modules:

Component	Hostnaam	TLS-certificaat Rol	Functie
Node Besturingssysteem	node1.customer.com	Common Name (CN)	Kernorkestratie
Zoom Connector Proxy	zcp1.customer.com	Subject Alternative Name (SAN)	Signalering en sessiecontrole
Media Module Router 1	mmr1.customer.com	Subject Alternative Name (SAN)	Media-routering en -verwerking
Media Module Router 2	mmr2.customer.com	Subject Alternative Name (SAN)	Media-routering en -verwerking
Media Module Router 3	mmr3.customer.com	Subject Alternative Name (SAN)	Media-routering en -verwerking

U moet aan elke module een toegewijd statisch IP-adres Toewijzen. Totaal vereist aantal IP-adressen: vijf (5)

De bovenstaande afbeelding schetst de minimale configuratie die nodig is om Zoom Phone Local Survivability (ZPLS). ZPLS maakt voortgezette beschikbaarheid van telefoondiensten mogelijk in het geval van internet- of Cloud-verstoring door survivability-logica lokaal op een Zoom Node VM uit te voeren.

De volgende hostnamen moeten in DNS worden geconfigureerd en in het TLS-certificaat worden opgenomen:

• node1.customer.com

• zplsl.customer.com

Functionele mapping van hostnamen

Component	Hostnaam	TLS-certificaat Rol	Functie
Node Besturingssysteem	node1.customer.com	Common Name (CN)	Kernorkestratie
ZPLS-module	zplsl.customer.com	Subject Alternative Name	Logica voor Zoom Phone Local Survivability

TLS-certificaatconfiguratie

Veld	Waarde
Common Name (CN)	node1.customer.com
Subject Alternative Names	zplsl.customer.com

Certificaten moeten worden gegenereerd of aangeschaft (publieke of private CA) om zowel de CN als de SAN's hierboven op te nemen. Dit maakt een juiste TLS-validatie mogelijk voor veilige communicatie binnen de module.

Vereisten voor IP-adres

Metriek	Waarde / Beschrijving
Totaal vereist aantal IP-adressen	5 (algemene toewijzing)
Gebruikt in ZPLS-context	2 IP's (1 voor Node Besturingssysteem, 1 voor ZPLS-module)

Hoewel voor een algemene implementatie vijf (5) IP-adressen vereist zijn, worden slechts twee (2) IP-adressen actief gebruikt in de ZPLS-implementatie: één per module, draaiend op een toegewijde Node-VM.

ZPLS staat slechts één module per Node-VM toe. U kunt ZPLS niet samen met andere Zoom-modules op dezelfde VM plaatsen.

Hoe verhouden deze diagrammen zich tot elkaar? De eerste afbeelding toont een voorbeeld van een Zoom Meetings Hybrid-implementatie. De tweede afbeelding toont een voorbeeld van een Zoom Phone Local Survivability-implementatie.

U kunt desgewenst de eerste IP/hostnaam delen tussen het Besturingssysteem en de eerste module om het aantal vereiste IP-adressen, hostnamen en Subject Alternative Names (SANs) te verminderen.

Optie 2: Zoom Meetings Hybrid geïmplementeerd met een gedeeld IP-adres en een gedeelde hostnaam

Deze configuratie herhaalt de Node-structuur zoals te zien is in het Zoom Meetings Hybrid-diagram van Optie 1. In deze implementatie echter, de Het Node-Besturingssysteem deelt zijn IP-adres met de eerst geïmplementeerde module (meestal de Zoom Connector Proxy, ZCP). Dit resulteert in minder IP-adresgebruik terwijl TLS en functionele vereisten behouden blijven.

De volgende hostnamen moeten in DNS worden geconfigureerd en in het TLS-certificaat worden opgenomen:

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

Functionele mapping van hostnamen

Component	Hostnaam	TLS-certificaat Rol	Functie
ZCP (Zoom Connector Proxy)	zcp1.customer.com	Common Name (CN)	Signalering en sessiecontrole
Media Module Router 1	mmr1.customer.com	Subject Alternative Name (SAN)	Media-routering en -verwerking
Media Module Router 2	mmr2.customer.com	Subject Alternative Name (SAN)	Media-routering en -verwerking
Media Module Router 3	mmr3.customer.com	Subject Alternative Name (SAN)	Media-routering en -verwerking

TLS-certificaatconfiguratie

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

Certificaten moeten alle SAN's bevatten om veilige TLS-communicatie tussen de Zoom Node en de geïnstalleerde Zoom-modules te ondersteunen.

Vereisten voor IP-adres

Metriek	Waarde / Beschrijving
Totaal vereist aantal IP-adressen	4
IP-deelstrategie	Besturingssysteem van de node deelt IP met eerste module (ZCP)
Afzonderlijke IP-adressen vereist voor	ZCP/MMR1, MMR2, MMR3

Wanneer het IP-adres gedeeld tussen het Besturingssysteem van de node en de eerst geïmplementeerde module (ZCP), alleen vier (4) IP-adressen zijn vereist. Dit ontwerp optimaliseert het IP-gebruik en voldoet nog steeds aan de implementatiestandaarden.

De bovenstaande afbeelding toont een minimale ZPLS-implementatie waarbij de Besturingssysteem van de Node deelt zijn IP-adres met de geïnstalleerde ZPLS-module. Dit is de enige scenario in het Zoom Node-framework waarin een TLS-certificaat voor één host geldig is.

De volgende hostnaam moet in DNS worden geconfigureerd en opgenomen in het TLS-certificaat:

• zplsl.customer.com

Functionele mapping van hostnamen

Component	Hostnaam	TLS-certificaat Rol	Functie
ZPLS-module	zplsl.customer.com	Common Name (CN)	Logica voor Zoom Phone Local Survivability

TLS-certificaatconfiguratie

Veld	Waarde
Common Name (CN)	zcp1.customer.com
SAN's	(niet vereist)

In deze configuratie is een single-host certificaat voldoende, omdat zowel het Besturingssysteem als de ZPLS-module dezelfde hostnaam en IP-adres delen.

Vereisten voor IP-adres

Metriek	Waarde / Beschrijving
Totaal vereist aantal IP-adressen	1
IP-deelstrategie	Node Besturingssysteem en ZPLS delen één IP-adres
Implementatiebeperking	Slechts één module toegestaan per Node VM (alleen ZPLS)

ZPLS is het enige ondersteunde scenario in de Zoom Node-architectuur waarbij:

• Een single-host certificaat (alleen CN) is acceptabel

• Voor implementatie is slechts één (1) IP-adres vereist vanwege het delen van IP-adressen tussen Besturingssysteem en module

• Co-locatie van extra modules op dezelfde VM wordt niet ondersteund

Bepaal welke certificaatbeheer-methode het beste werkt voor uw implementaties

Elk Service Module dat op Zoom Node is geïmplementeerd, vereist een geldig certificaat dat is ondertekend door een publiek vertrouwde certificaatautoriteit (CA) uit de certificaatvertrouwenslijst van Zoom Node. Dit omvat bekende publieke autoriteiten.

Zoom Node biedt twee methoden voor certificaatbeheer:

• Automatische PKI: Deze innovatieve oplossing automatiseert veilige certificaatinschrijving en -verlenging bij openbaar vertrouwde certificaatautoriteiten (CA's). Zoom dekt de kosten die gepaard gaan met inschrijving en verlenging.

• Neem uw eigen certificaat mee (BYOC): Met deze optie levert u uw eigen certificaten, ondertekend door een grote publiek vertrouwde CA. U beheert de certificaatuitgifte en vernieuwingen. Er gelden aanvullende overwegingen met betrekking tot het potentieel van Zoom Node voor maximaal vijf hostnamen/SAN's bij gebruik van door de klant aangeleverde certificaten, die hieronder verder worden beschreven.

Automatisch certificaatbeheer met Auto PKI

Zoom Auto PKI installeert automatisch geldige, publiek vertrouwde CA-certificaten voor het Zoom Node Platform, evenals voor alle modules die daarop zijn geïmplementeerd. Verlenging van certificaten wordt ook automatisch afgehandeld. Dit vereenvoudigt het certificaatbeheer voor alle services en voor Zoom Node zelf.

Inzicht in Auto PKI-certificaatinschrijving en -vernieuwing

Het volgende scenario kan u helpen begrijpen hoe certificaatinschrijving en -vernieuwing werkt.

Bijvoorbeeld: een beheerder heeft een nieuwe Node-instantie geïmplementeerd. Elke instantie vereist een geldig x509-certificaat. De privé sleutel van het certificaat mag deze instantie nooit verlaten.

Het Auto PKI-proces voert de volgende stappen uit:

1. Sjabloonophaling: Haalt alle ondersteunde configuratiesjablonen op, inclusief opties voor meerdere CA-providers, van de Auto PKI-service in de Zoom-cloud.

2. IP-adresverzameling: Verzamelt alle IP-adressen die door services op de Node worden gebruikt en stuurt ze naar de Auto PKI-service in de Zoom-cloud.

3. DNS-naamvoorziening: De Auto PKI Cloud-service geeft een set DNS-namen terug in het formaat <instance_Identificatie>.<customer_Identificatie>.zoomonprem.com. Deze domeinen zijn geconfigureerd met A/AAAA-records.

4. Aanvraag voor gereserveerde DNS-naam: Vraagt een gereserveerde DNS-naam aan in de indeling rsvd-<randomized_string>.<customer_Identificatie>.zoomonprem.com.

5. Genereren van certificaataanvraag: Genereert een x509-certificaataanvraag, waarbij de DNS-namen uit de derde stap in het SAN-veld worden gebruikt en de gereserveerde naam uit de vierde stap in het veld Common Name (CN).

6. Certificaatuitgifte: Verstuurt de certificaatondertekeningsaanvraag (CSR) naar de Auto PKI-service in de Zoom-cloud. Deze service werkt vervolgens samen met CA-leveranciers om het certificaat uit te geven, dat de SAN-lijst en het CN-veld uit de vorige stap bevat.

7. Lokale opslag: Schrijft het nieuw uitgegeven x509-certificaat van de laatste stap en de bijbehorende privésleutel (eerder gegenereerd) naar lokale opslag, waardoor ze Beschikbaar worden voor services die op de Node-instantie worden uitgevoerd.

Auto PKI vereenvoudigt certificaatbeheer op Zoom Node door vervaldatums automatisch te bewaken en nieuwe certificaten aan te vragen, waardoor handmatige verlenging niet meer nodig is.

Breng uw eigen certificaten mee (BYOC)

U kunt uw eigen geldige, publiek ondertekende certificaten op Zoom Node installeren via de lokale webinterface. U kunt dit doen tijdens de eerste installatie of op een later moment. Het proces zal vertrouwd aanvoelen voor iedereen die gewend is certificaten te installeren op webgebaseerde toepassingen.

Als u ervoor kiest uw eigen certificaten te gebruiken, houd er dan rekening mee dat het certificaat zich op een server zal bevinden die communiceert met meerdere hostnamen. Daarom moet het certificaattype dat u kiest encryptie ondersteunen voor verkeer dat afkomstig is van meer dan één hostnaam (certificaat-CN). Alle hostnamen die worden gebruikt voor Node en eventuele geïmplementeerde services moeten publiek oplosbaar zijn via Zoom's Cloudservices.

Zoom raadt twee soorten certificaten aan:

• Wildcard-certificaat

• Multi-SAN-certificaat (ook bekend als Multi-Domain-certificaat, SAN-certificaat of UCC-certificaat)

Een typisch certificaat voor één host werkt niet met Zoom Node, behalve in het specifieke scenario waarin één IP-adres en hostnaam worden gedeeld tussen Zoom Node en één module. Zie voor extra context het ZPLS-diagram in de Overwegingen voor Zoom Node-implementatie sectie.

Wildcard-certificaten: Aanbevolen voor eenvoud

Een wildcard-certificaat kan verkeer versleutelen van elke hostnaam in het domein. Bijvoorbeeld: een wildcard-certificaat zoals *.customer.com kan verkeer versleutelen van host1.customer.com en host2.customer.com of elke naam binnen .customer.com.

Wanneer u Zoom Node implementeert en het wildcard-certificaat installeert, wordt het verkeer voor alle services die u op de Node implementeert automatisch versleuteld, met de vereiste dat alle geïmplementeerde Services een Fully Qualified Domain Name (FQDN) uit het wildcarddomein gebruiken.

Dit minimaliseert de inspanning om services op de Node te implementeren: u hoeft de namen van de services niet te kennen voordat u ze implementeert. U moet echter de servicenamen kennen als u de multi-SAN-certificaatmethode gebruikt.

Multi-SAN-, Multi-Domain-, SAN- of UCC-certificaten

U moet de hostnamen en IP-adressen kennen die u gaat gebruiken voor de Node (maximaal één [1]) en eventuele Services die u gaat installeren (maximaal vier [4]).

Deze informatie is vereist voordat u een certificaat registreert.

Een Multi-SAN-certificaat is noodzakelijk voor Zoom Node omdat het verkeer van vijf (5) hostnamen versleutelt. Voor een eenmalige aanvraag voor dit certificaat is vooraf kennis nodig van alle benodigde informatie, inclusief geplande Node-namen en de namen van alle services die voor implementatie op de Node zijn gepland. Bijvoorbeeld, met een module zoals ZPLS wordt slechts één ZPLS-module per Node geïmplementeerd, dus is slechts één extra SAN nodig voor de hostnaam van de ZPLS-service.

De volgende tabel kan als voorbeeld worden gebruikt:

Hostnaam (SAN)	IP-adres
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 - niet gebruikt in dit voorbeeld)	(N.v.t.)

Dit voorbeeld is een typische configuratie, met één Node waarop ZPLS op hetzelfde IP wordt gehost plus twee დამატionele services op afzonderlijke IP's. Vervang “company.com” door uw daadwerkelijke domein en gebruik de IP-adressen van uw netwerk.

Vereisten voor DNS-resolutie

Zoom vereist dat de hostnamen publiek kunnen worden opgelost, zodat tweezijdig vertrouwen kan worden vastgesteld. Alle hostnamen van Zoom Node en alle servicehostnamen die op de Nodes zijn geïmplementeerd, moeten in de DNS-zone zijn opgenomen.

Als uw Organisatie afzonderlijke interne en externe DNS-services of domeinen gebruikt, moeten de hostnamen van Zoom Node worden gehost in een zone die door uw externe DNS-servers kan worden opgelost (kan worden beperkt tot alleen resolutie voor Zoom-IP-bereiken). Uw interne Zoom-gebruikers en de Zoom-cloud moeten communiceren met dezelfde set hostnamen.