Overwegingen bij de implementatie van Zoom Node

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

Deze sectie bevat verschillende voorbeelden van hoe Zoom Node ondersteuning kan bieden aan verschillende service-modules zoals Zoom Meetings Hybrid en Zoom Phone Local Survivability (ZPLS). Typische implementaties met een toegewezen IP-adres kunnen eruitzien als de volgende verzameling diagrammen.

Elke service die op Zoom Node is geïmplementeerd, vereist een uniek IP-adres. Een Zoom Node heeft maximaal vijf (5) IP-adressen toegewezen als de Node een specifiek adres voor beheer heeft gekregen en één voor elke geïmplementeerde service (tot vier) op de Node. Een Zoom Node die één service draait (zoals ZPLS) kan met één IP-adres worden geïmplementeerd als de Node en de service zo worden ingesteld dat ze hetzelfde IP-adres delen.

Hieronder worden verschillende implementatieopties getoond. Let op het aantal IP's en certificaten (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 IP- en certificaatconfiguratievereisten samen voor het implementeren van Zoom Meetings Hybrid in on-premises- of hybride Cloud-omgevingen.

De onderstaande tabel werkt de voorbeeld-Node uit en bevat de actieve proxy en MMR-service-modules:

Component	Hostnaam	Rol van TLS-certificaat	Functie
Node-Besturingssysteem	node1.customer.com	Algemene naam (CN)	Kernorkestratie
Zoom Connector Proxy	zcp1.customer.com	Alternatieve subjectnaam (SAN)	Signalisering en sessiecontrole
Media Module Router 1	mmr1.customer.com	Alternatieve subjectnaam (SAN)	Media Routering en verwerking
Media Module Router 2	mmr2.customer.com	Alternatieve subjectnaam (SAN)	Media Routering en verwerking
Media Module Router 3	mmr3.customer.com	Alternatieve subjectnaam (SAN)	Media Routering en verwerking

U moet aan elke module een specifiek statisch IP-adres toewijzen. Totaal vereiste IP-adressen: vijf (5)

De bovenstaande afbeelding schetst de minimale configuratie die nodig is om te implementeren Lokale veerkracht van Zoom Phone (ZPLS). ZPLS zorgt voor continue beschikbaarheid van de telefoondienst bij een internet- of Cloud-storing door overlevingslogica lokaal uit te voeren op een Zoom Node VM.

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

• node1.customer.com

• zplsl.customer.com

Functionele hostnaamkoppeling

Component	Hostnaam	Rol van TLS-certificaat	Functie
Node-Besturingssysteem	node1.customer.com	Algemene naam (CN)	Kernorkestratie
ZPLS-module	zplsl.customer.com	Alternatieve subjectnaam	Zoom Phone lokale overlevingslogica

TLS-certificaatconfiguratie

Veld	Waarde
Algemene naam (CN)	node1.customer.com
Alternatieve subjectnamen	zplsl.customer.com

Certificaten moeten worden gegenereerd of verkregen (openbare of private CA) om zowel de hierboven vermelde CN als SAN's op te nemen. Dit maakt correcte TLS-validatie mogelijk voor veilige communicatie tussen modules.

IP-adresvereisten

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

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

ZPLS staat alleen één module per Node-VM toe. U kunt ZPLS niet op dezelfde VM naast andere Zoom-modules 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 indien gewenst het eerste IP-adres/de eerste 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 diagram van Zoom Meetings Hybrid in Optie 1. In deze implementatie is echter het Het Besturingssysteem van de Node deelt zijn IP-adres met de eerst geïmplementeerde module (meestal de Zoom Connector Proxy, ZCP). Dit resulteert in minder IP-gebruik terwijl aan TLS- en functionele vereisten wordt voldaan.

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

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

Functionele hostnaamkoppeling

Component	Hostnaam	Rol van TLS-certificaat	Functie
ZCP (Zoom Connector Proxy)	zcp1.customer.com	Algemene naam (CN)	Signalisering en sessiecontrole
Media Module Router 1	mmr1.customer.com	Alternatieve subjectnaam (SAN)	Media Routering en verwerking
Media Module Router 2	mmr2.customer.com	Alternatieve subjectnaam (SAN)	Media Routering en verwerking
Media Module Router 3	mmr3.customer.com	Alternatieve subjectnaam (SAN)	Media Routering en verwerking

TLS-certificaatconfiguratie

Veld	Waarde
Algemene naam (CN)	zcp1.customer.com
Alternatieve subjectnamen	mmr1.customer.com, mmr2.customer.com, mmr3.customer.com

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

IP-adresvereisten

Meetwaarde	Waarde / Beschrijving
Totaal vereiste IP-adressen	4
IP-deelstrategie	Node Besturingssysteem deelt IP met de eerste module (ZCP)
Individuele IP's vereist voor	ZCP/MMR1, MMR2, MMR3

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

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

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

• zplsl.customer.com

Functionele hostnaamkoppeling

Component	Hostnaam	Rol van TLS-certificaat	Functie
ZPLS-module	zplsl.customer.com	Algemene naam (CN)	Zoom Phone lokale overlevingslogica

TLS-certificaatconfiguratie

Veld	Waarde
Algemene naam (CN)	zcp1.customer.com
SAN's	(niet vereist)

In deze configuratie is een certificaat voor één host voldoende, aangezien zowel het Besturingssysteem als de ZPLS-module dezelfde hostnaam en hetzelfde IP-adres delen.

IP-adresvereisten

Meetwaarde	Waarde / Beschrijving
Totaal vereiste 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 certificaat voor één host (alleen CN) is acceptabel

• Er is slechts één (1 )IP-adres vereist voor implementatie vanwege IP-deling van de Besturingssysteem-module

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

Bepaal welke methode voor certificaatbeheer het beste werkt voor uw implementaties

Elke Service Module die op Zoom Node wordt 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:

• Auto PKI: Deze innovatieve oplossing automatiseert veilige certificaatinschrijving en -vernieuwing met publiek vertrouwde certificaatautoriteiten (CA's). Zoom dekt de kosten die verband houden met inschrijving en vernieuwing.

• Breng uw eigen certificaat (BYOC): Met deze optie levert u uw eigen certificaten, ondertekend door een grote publiek vertrouwde CA. U beheert de certificaatinschrijving en -vernieuwingen. Er gelden aanvullende overwegingen met betrekking tot het potentieel van Zoom Node voor maximaal vijf hostnames/SAN's bij gebruik van door de klant geleverde 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 alle modules die daarop zijn geïmplementeerd. Certificaatvernieuwing wordt ook automatisch afgehandeld. Dit vereenvoudigt het certificaatbeheer voor alle services en Zoom Node zelf.

Begrijpen van certificaatinschrijving en -vernieuwing met Auto PKI

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

Bijvoorbeeld: een beheerder heeft een nieuwe Node-instantie geïmplementeerd. Voor elke instantie is een geldig x509-certificaat vereist. 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. Verzameling van IP-adressen: Verzamelt alle IP-adressen die worden gebruikt door services die op de Node draaien en stuurt ze naar de Auto PKI-service in de Zoom-cloud.

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

4. Aanvraag voor gereserveerde DNS-naam: Vraagt een gereserveerde DNS-naam op in de vorm 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 Common Name (CN)-veld.

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

7. Lokale opslag: Schrijft het nieuw uitgegeven x509-certificaat uit de laatste stap en de bijbehorende privésleutel (eerder gegenereerd) naar de lokale opslag, zodat deze beschikbaar zijn voor services die op de Node-instantie draaien.

Auto PKI vereenvoudigt het certificaatbeheer op Zoom Node door automatisch vervaldata 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 zijn voor degenen die gewend zijn certificaten op webgebaseerde toepassingen te installeren.

Als u ervoor kiest uw eigen certificaten te gebruiken, vergeet dan niet dat het certificaat zich op een server bevindt die communiceert met meerdere hostnamen. Kies een certificaattype dat ondersteuning biedt voor encryptie van verkeer dat afkomstig is van meer dan één hostnaam (certificaat-CN). Alle hostnamen die voor Node en alle geïmplementeerde services worden gebruikt, moeten publiek kunnen worden opgelost door de Cloudservices van Zoom.

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. Voor extra context, zie het ZPLS-diagram in de Overwegingen bij de implementatie van Zoom Node sectie.

Wildcard-certificaten: aanbevolen voor eenvoud

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

Wanneer u Zoom Node implementeert en het wildcard-certificaat installeert, zal het automatisch verkeer versleutelen voor alle services die u op de Node implementeert, 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-certificaattypen

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

Deze informatie is vereist voordat u een certificaat aanvraagt.

Een Multi-SAN-certificaat is noodzakelijk voor Zoom Node omdat het verkeer van vijf (5) hostnamen versleutelt. Een eenmalige aanvraag voor dit certificaat vereist vooraf kennis van alle noodzakelijke informatie, inclusief geplande Node-namen en de namen van alle services die op de Node zullen worden uitgerold. Bijvoorbeeld: bij een module zoals ZPLS wordt per Node slechts één ZPLS-module uitgerold, 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 die ZPLS host op hetzelfde IP plus twee extra services op afzonderlijke IP's. Vervang “company.com” door uw eigen domein en gebruik de IP-adressen van uw netwerk.

Vereisten voor DNS-resolutie

Zoom vereist dat de hostnamen publiekelijk resolvable zijn, zodat wederzijds vertrouwen kan worden opgebouwd. Alle Zoom Node-hostnamen en alle servicenames die op de Nodes zijn geïmplementeerd, moeten in de DNS-zone worden opgenomen.

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