Considerazioni sulla distribuzione di Zoom Node

Scopri di più su come i vari esempi di distribuzione supportano Zoom Node e i moduli di servizio di Zoom Node

Questa sezione contiene diversi esempi di come Zoom Node può supportare vari Moduli di Servizio come Zoom Meetings Hybrid e Zoom Phone Local Survivability (ZPLS). Le distribuzioni tipiche con un Indirizzo IP dedicato possono apparire come la seguente raccolta di diagrammi.

Ogni servizio distribuito su Zoom Node richiede un Indirizzo IP univoco. A un Zoom Node verranno assegnati fino a cinque (5) indirizzi IP se al Node è stato assegnato un indirizzo specifico per la gestione e uno per ogni servizio distribuito (fino a quattro) sul Node. Un Zoom Node che esegue un singolo servizio (come ZPLS) può essere distribuito con un solo Indirizzo IP se al Node e al servizio viene assegnato di condividere lo stesso Indirizzo IP.

Di seguito sono mostrate diverse opzioni di distribuzione. Notare il numero di IP e certificati (CN/SAN) per le varie opzioni di distribuzione.

Opzione 1: Zoom Meetings Hybrid distribuito con IP e nomi host dedicati

L'immagine sopra riassume i requisiti di configurazione di IP e certificato per distribuire Zoom Meetings Hybrid in ambienti on-premise o cloud ibridi.

La tabella seguente suddivide il Node di esempio e include i suoi Moduli di Servizio proxy attivo e MMR:

Componente	Nome host	Ruolo del certificato TLS	Funzione
sistema operativo del Node	node1.customer.com	Nome comune (CN)	Orchestrazione principale
Proxy Connettore Zoom	zcp1.customer.com	Nome alternativo del soggetto (SAN)	Segnalazione e controllo della sessione
Router del modulo multimediale 1	mmr1.customer.com	Nome alternativo del soggetto (SAN)	Instradamento ed elaborazione multimediale
Router del modulo multimediale 2	mmr2.customer.com	Nome alternativo del soggetto (SAN)	Instradamento ed elaborazione multimediale
Router del modulo multimediale 3	mmr3.customer.com	Nome alternativo del soggetto (SAN)	Instradamento ed elaborazione multimediale

Devi Assegna a ogni modulo un Indirizzo IP statico dedicato. Totale indirizzi IP richiesti: cinque (5)

L'immagine sopra illustra la configurazione minima necessaria per distribuire Zoom Phone Local Survivability (ZPLS). ZPLS consente la disponibilità continua del servizio telefonico in caso di interruzione di internet o del cloud eseguendo localmente la logica di sopravvivenza su una VM Zoom Node.

I seguenti nomi host devono essere configurati nel DNS e inclusi nel certificato TLS:

• node1.customer.com

• zplsl.customer.com

Mappatura funzionale del nome host

Componente	Nome host	Ruolo del certificato TLS	Funzione
sistema operativo del Node	node1.customer.com	Nome comune (CN)	Orchestrazione principale
Modulo ZPLS	zplsl.customer.com	Nome alternativo del soggetto	Logica di Zoom Phone Local Survivability

Configurazione del certificato TLS

Campo	Valore
Nome comune (CN)	node1.customer.com
Nomi alternativi del soggetto	zplsl.customer.com

I certificati devono essere generati o procurati (CA pubblica o privata) per includere sia il CN sia i SAN sopra elencati. Questo consente una corretta convalida TLS per una comunicazione intra-modulo sicura.

Requisiti dell'indirizzo IP

Metrica	Valore / Descrizione
Totale indirizzi IP richiesti	5 (allocazione generale)
Utilizzato nel contesto ZPLS	2 IP (1 per il sistema operativo del Node, 1 per il modulo ZPLS)

Mentre cinque (5) IP sono richiesti per la distribuzione generale, solo due (2) Indirizzi IP sono utilizzati attivamente nel deployment ZPLS: uno per modulo, in esecuzione su un Node VM dedicato.

ZPLS consente solo un modulo per Node VM. Non è possibile co-localizzare ZPLS con altri moduli Zoom sulla stessa VM.

In che modo questi diagrammi si confrontano? La prima immagine mostra un esempio di un deployment ibrido di Zoom Meetings. La seconda immagine mostra un esempio di un deployment di Zoom Phone Local Survivability.

Se desiderato, è possibile condividere il primo IP/nome host tra il sistema operativo e il primo modulo, per ridurre il numero di Indirizzi IP, nomi host e Subject Alternative Names (SANs) richiesti.

Opzione 2: Zoom Meetings Hybrid distribuito con un IP condiviso e un nome host condiviso

Questa configurazione ripete la struttura Node come si vede nel diagramma di Zoom Meetings Hybrid dell'Opzione 1. Tuttavia, in questo deployment, il il sistema operativo del Node condivide il proprio Indirizzo IP con il primo modulo distribuito (tipicamente il Proxy di Zoom Connettore, ZCP). Ciò comporta una riduzione dell'utilizzo degli Indirizzi IP, mantenendo al contempo i requisiti TLS e funzionali.

I seguenti nomi host devono essere configurati nel DNS e inclusi nel certificato TLS:

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

Mappatura funzionale del nome host

Componente	Nome host	Ruolo del certificato TLS	Funzione
ZCP (Proxy del Connettore Zoom)	zcp1.customer.com	Nome comune (CN)	Segnalazione e controllo della sessione
Router del modulo multimediale 1	mmr1.customer.com	Nome alternativo del soggetto (SAN)	Instradamento ed elaborazione multimediale
Router del modulo multimediale 2	mmr2.customer.com	Nome alternativo del soggetto (SAN)	Instradamento ed elaborazione multimediale
Router del modulo multimediale 3	mmr3.customer.com	Nome alternativo del soggetto (SAN)	Instradamento ed elaborazione multimediale

Configurazione del certificato TLS

Campo	Valore
Nome comune (CN)	zcp1.customer.com
Nomi alternativi del soggetto	mmr1.customer.com, mmr2.customer.com, mmr3.customer.com

I certificati devono includere tutti i SAN per supportare una comunicazione TLS sicura tra il Zoom Node e i moduli Zoom installati.

Requisiti dell'indirizzo IP

Metrica	Valore / Descrizione
Totale indirizzi IP richiesti	4
Strategia di condivisione dell'Indirizzo IP	Il sistema operativo del Node condivide l'Indirizzo IP con il primo modulo (ZCP)
Indirizzi IP individuali richiesti per	ZCP/MMR1, MMR2, MMR3

Quando l'Indirizzo IP è condiviso tra il sistema operativo del Node e il primo modulo distribuito (ZCP), solo quattro (4) indirizzi IP sono richiesti. Questa progettazione ottimizza l'utilizzo degli IP pur continuando a rispettare gli standard di distribuzione.

L'immagine sopra mostra una distribuzione ZPLS minima in cui il sistema operativo del nodo condivide il suo Indirizzo IP con il modulo ZPLS installato. Questo è il solo scenario nel framework Zoom Node in cui un certificato TLS single-organizzatore è valido.

Il seguente nome organizzatore deve essere configurato nel DNS e incluso nel certificato TLS:

• zplsl.customer.com

Mappatura funzionale del nome host

Componente	Nome host	Ruolo del certificato TLS	Funzione
Modulo ZPLS	zplsl.customer.com	Nome comune (CN)	Logica di Zoom Phone Local Survivability

Configurazione del certificato TLS

Campo	Valore
Nome comune (CN)	zcp1.customer.com
SAN	(non richiesto)

In questa configurazione, è sufficiente un certificato per organizzatore singolo poiché sia il sistema operativo sia il modulo ZPLS condividono lo stesso nome organizzatore e lo stesso Indirizzo IP.

Requisiti dell'indirizzo IP

Metrica	Valore / Descrizione
Totale indirizzi IP richiesti	1
Strategia di condivisione dell'Indirizzo IP	Il sistema operativo del nodo e ZPLS condividono un unico Indirizzo IP
Vincolo di distribuzione	È consentito un solo modulo per VM del nodo (solo ZPLS)

ZPLS è l'unico scenario supportato nell'architettura Zoom Node in cui:

• È accettabile un certificato per organizzatore singolo (solo CN)

• Per la distribuzione è richiesto un solo (1) Indirizzo IP grazie alla condivisione dell'IP tra sistema operativo e modulo

• La co-locazione di moduli aggiuntivi sulla stessa VM non è supportata

Decidi quale metodo di gestione dei certificato funziona meglio per le tue distribuzioni

Ogni Modulo di Servizio distribuito su Zoom Node richiede un certificato valido firmato da un'Autorità di certificazione (CA) pubblicamente attendibile dell'elenco di attendibilità dei certificati di Zoom Node. Ciò include autorità pubbliche ben note.

Zoom Node offre due metodi di gestione dei certificati:

• Auto PKI: Questa soluzione innovativa automatizza la registrazione e il rinnovo sicuri dei certificati con Autorità di certificazione (CA) pubblicamente attendibili. Zoom copre i costi associati alla registrazione e al rinnovo.

• Porta il tuo certificato (BYOC): Con questa opzione, fornisci i tuoi certificati, firmati da qualsiasi importante CA pubblicamente attendibile. Ti occupi della registrazione e dei rinnovi dei certificati. Si applicano ulteriori considerazioni riguardo al potenziale di Zoom Node fino a cinque nomi host/SAN quando si utilizzano certificati forniti dal cliente, descritte più dettagliatamente di seguito.

Gestione automatica dei certificati con Auto PKI

Zoom Auto PKI installa automaticamente certificati CA validi e pubblicamente attendibili per la piattaforma Zoom Node, nonché per tutti i moduli distribuiti su di essa. Anche il rinnovo dei certificati viene gestito automaticamente. Questo semplifica la gestione dei certificati per tutti i servizi e per lo stesso Zoom Node.

Comprendere la registrazione e il rinnovo dei certificati Auto PKI

Lo scenario seguente può aiutarti a capire come funzionano la registrazione e il rinnovo dei certificati.

Ad esempio: un amministratore ha distribuito una nuova istanza Node. Ogni istanza richiede un certificato x509 valido. La chiave privata del certificato non deve mai lasciare questa istanza.

Il processo Auto PKI esegue i seguenti passaggi:

1. Recupero dei modelli: Recupera tutti i modelli di configurazione supportati, comprese le opzioni per più provider CA, dal servizio Auto PKI nel cloud Zoom.

2. Raccolta degli Indirizzo IP: Raccoglie tutti gli Indirizzo IP utilizzati dai servizi in esecuzione sul Node e li invia al servizio Auto PKI nel cloud Zoom.

3. Provisioning dei nomi DNS: Il servizio cloud Auto PKI restituisce un insieme di nomi DNS nel formato <instance_identificativo>.<customer_identificativo>.zoomonprem.com. Questi domini sono configurati con record A/AAAA.

4. Richiesta di nome DNS riservato: Richiede un nome DNS riservato nel formato rsvd-<randomized_string>.<customer_identificativo>.zoomonprem.com.

5. Generazione della richiesta di certificato: Genera una richiesta di certificato x509, utilizzando i nomi DNS del terzo passaggio nel campo SAN e il nome riservato del quarto passaggio nel campo Common Name (CN).

6. Emissione certificato: Invia la richiesta di firma del certificato (CSR) al servizio Auto PKI nel cloud Zoom. Questo servizio lavora quindi con i fornitori CA per emettere il certificato, che include l'elenco SAN e il campo CN del passaggio precedente.

7. Archiviazione locale: Scrive il certificato x509 appena emesso dall'ultimo passaggio e la relativa chiave privata (generata in precedenza) nell'archiviazione locale, rendendoli Disponibile per i servizi in esecuzione sull'istanza Node.

Auto PKI semplifica la gestione dei certificati su Zoom Node monitorando automaticamente le date di scadenza e richiedendo nuovi certificati, eliminando la necessità di rinnovo manuale.

Bring Your Own Certificates (BYOC)

Puoi installare i tuoi certificati validi e firmati pubblicamente su Zoom Node usando l'interfaccia web locale. Puoi farlo durante l'installazione iniziale oppure in un secondo momento. Il processo sarà familiare a chi è abituato a installare certificati su applicazioni basate sul web.

Se scegli di usare i tuoi certificati, ricorda che il certificato sarà su un server che comunica con più hostname. Pertanto, il tipo di certificato che scegli deve supportare la crittografia del traffico proveniente da più di un hostname (CN del certificato). Tutti gli hostname usati per Node e per eventuali servizi distribuiti devono essere risolvibili pubblicamente dai servizi cloud di Zoom.

Zoom consiglia due tipi di certificati:

• Certificato Wildcard

• Certificato Multi-SAN (noto anche come Certificato Multi-Domain, Certificato SAN o Certificato UCC)

Un tipico certificato per un singolo organizzatore non funzionerà con Zoom Node, tranne nello scenario specifico in cui un singolo Indirizzo IP e hostname sono condivisi tra Zoom Node e un singolo modulo. Per ulteriori informazioni, consulta il diagramma ZPLS nella Considerazioni sulla distribuzione di Zoom Node sezione.

Certificati wildcard: consigliati per semplicità

Un certificato wildcard può crittografare il traffico da qualsiasi hostname nel dominio. Ad esempio: un certificato wildcard come *.customer.com può crittografare il traffico da host1.customer.com e host2.customer.com o qualsiasi nome all'interno di .customer.com.

Quando distribuisci Zoom Node e installi il certificato wildcard, crittograferà automaticamente il traffico per tutti i servizi che distribuisci sul Node, a condizione che tutti i Servizi distribuiti utilizzino un Fully Qualified Domain Name (FQDN) del dominio wildcard.

Questo riduce al minimo l'impegno necessario per distribuire i servizi sul Node: non devi conoscere i nomi dei servizi prima di distribuirli. Tuttavia, devi conoscere i nomi dei servizi se utilizzi il metodo del certificato multi-SAN.

Certificati Multi-SAN, Multi-Domain, SAN o UCC

Devi conoscere gli hostname e gli indirizzi IP che utilizzerai per il Node (fino a uno [1]) e gli eventuali Servizi che installerai (fino a quattro [4]).

Queste informazioni sono richieste prima di registrare un certificato.

Un certificato Multi-SAN è necessario per Zoom Node perché cripta il traffico di cinque (5) nomi host. Una richiesta una tantum per questo certificato richiede la conoscenza preventiva di tutte le informazioni necessarie, inclusi i nomi pianificati dei Node e i nomi di tutti i servizi previsti per la distribuzione sul Node. Ad esempio, con un modulo come ZPLS, viene distribuito un solo modulo ZPLS per Node, quindi è necessario un solo SAN aggiuntivo per il nome host del servizio ZPLS.

La seguente tabella può essere usata come esempio:

Nome host (SAN)	Indirizzo IP
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
(Servizio 4 - non usato in questo esempio)	(N/D)

Questo esempio mostra una configurazione tipica, con un Zoom Node che ospita ZPLS sullo stesso IP più altri due servizi su IP separati. Sostituite “company.com” con il vostro dominio effettivo e utilizzate gli indirizzi IP della vostra rete.

Requisiti di risoluzione DNS

Zoom richiede che gli hostname siano risolvibili pubblicamente in modo che possa essere stabilita una fiducia bidirezionale. Tutti gli hostname di Zoom Node e tutti gli hostname dei servizi distribuiti sui Node devono essere inclusi nella zona DNS.

Se la vostra Organizzazione gestisce servizi o domini DNS interni ed esterni separati, gli hostname di Zoom Node devono essere ospitati in una zona risolvibile dai vostri server DNS esterni (può essere limitata a risolvere solo per gli intervalli di IP di Zoom). I vostri utenti interni di Zoom e il cloud Zoom devono comunicare utilizzando lo stesso insieme di hostname.