# Considerazioni sul deployment 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 tipiche implementazioni con un indirizzo IP dedicato possono apparire come la seguente raccolta di diagrammi. Ogni servizio distribuito su Zoom Node richiede un indirizzo IP univoco. Un Zoom Node avrà fino a cinque (5) indirizzi IP assegnati se al Node è stato assegnato un indirizzo specifico per la gestione e uno per ciascun servizio distribuito (fino a quattro) sul Node. Un Zoom Node in esecuzione con un singolo servizio (come ZPLS) può essere distribuito con un singolo indirizzo IP se al Node e al servizio è assegnato di condividere lo stesso indirizzo IP. Di seguito sono mostrate diverse opzioni di distribuzione. Nota 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 degli IP e dei certificati per distribuire **Zoom Meetings Hybrid** in ambienti on-premise o cloud ibridi. La tabella seguente suddivide l'esempio di Node e include il suo proxy attivo e i Moduli di Servizio MMR: | Componente | Nome host | Ruolo del certificato TLS | Funzione | | --------------------- | -------------------- | ------------------------------ | --------------------------------------- | | OS del Node | `node1.customer.com` | Common Name (CN) | Orchestrazione centrale | | Zoom Connector Proxy | `zcp1.customer.com` | Subject Alternative Name (SAN) | Segnalazione e controllo della sessione | | Media Module Router 1 | `mmr1.customer.com` | Subject Alternative Name (SAN) | Instradamento e elaborazione dei media | | Media Module Router 2 | `mmr2.customer.com` | Subject Alternative Name (SAN) | Instradamento e elaborazione dei media | | Media Module Router 3 | `mmr3.customer.com` | Subject Alternative Name (SAN) | Instradamento e elaborazione dei media | {% hint style="info" %} Devi assegnare a ciascun modulo un indirizzo IP statico dedicato. Indirizzi IP totali richiesti: cinque (5) {% endhint %}
L'immagine sopra delinea la configurazione minima necessaria per distribuire **Zoom Phone Local Survivability (ZPLS)**. ZPLS consente la continuità del servizio telefonico in caso di interruzione di Internet o del cloud eseguendo la logica di sopravvivenza localmente 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 dei nomi host** | Componente | Nome host | Ruolo del certificato TLS | Funzione | | ----------- | -------------------- | ------------------------- | ---------------------------------------- | | OS del Node | `node1.customer.com` | Common Name (CN) | Orchestrazione centrale | | Modulo ZPLS | `zplsl.customer.com` | Subject Alternative Name | Logica di Zoom Phone Local Survivability | **Configurazione del certificato TLS** | Campo | Valore | | ------------------------- | -------------------- | | Common Name (CN) | `node1.customer.com` | | Subject Alternative Names | `zplsl.customer.com` | I certificati devono essere generati o procurati (CA pubblica o privata) per includere sia il CN che i SAN elencati sopra. Ciò consente una corretta validazione TLS per comunicazioni sicure intra-modulo. **Requisiti dell'indirizzo IP** | Metrica | Valore / Descrizione | | ----------------------------- | ------------------------------------------------ | | Indirizzi IP totali richiesti | 5 (allocazione generale) | | Utilizzato nel contesto ZPLS | 2 IP (1 per l'OS del Node, 1 per il modulo ZPLS) | Sebbene siano necessari cinque (5) IP per una distribuzione generale, **solo due (2) indirizzi IP sono attivamente utilizzati** nella distribuzione ZPLS: uno per modulo, in esecuzione su una **VM Node dedicata**. {% hint style="warning" %} ZPLS consente solo un modulo per VM Node. Non è possibile co-localizzare ZPLS con altri moduli Zoom sulla stessa VM. {% endhint %} Come si confrontano questi diagrammi? La prima immagine mostra un esempio di distribuzione Zoom Meetings Hybrid. La seconda immagine mostra un esempio di distribuzione Zoom Phone Local Survivability. Puoi condividere il primo IP/nome host tra il sistema operativo e il primo modulo, se desideri, per ridurre il numero di indirizzi IP, nomi host e Subject Alternative Names (SAN) richiesti. ### Opzione 2: Zoom Meetings Hybrid distribuito con IP condiviso e nome host condiviso
Questa configurazione ripete la struttura del Node come visto nel diagramma Zoom Meetings Hybrid dell'Opzione 1. Tuttavia, in questa distribuzione, il **OS del Node condivide il suo indirizzo IP con il primo modulo distribuito** (tipicamente lo Zoom Connector Proxy, ZCP). Ciò si traduce in una riduzione dell'utilizzo degli IP pur mantenendo 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 dei nomi host** | Componente | Nome host | Ruolo del certificato TLS | Funzione | | -------------------------- | ------------------- | ------------------------------ | --------------------------------------- | | ZCP (Zoom Connector Proxy) | `zcp1.customer.com` | Common Name (CN) | Segnalazione e controllo della sessione | | Media Module Router 1 | `mmr1.customer.com` | Subject Alternative Name (SAN) | Instradamento e elaborazione dei media | | Media Module Router 2 | `mmr2.customer.com` | Subject Alternative Name (SAN) | Instradamento e elaborazione dei media | | Media Module Router 3 | `mmr3.customer.com` | Subject Alternative Name (SAN) | Instradamento e elaborazione dei media | **Configurazione del certificato TLS** | Campo | Valore | | ------------------------- | ------------------------------------------------------------- | | Common Name (CN) | `zcp1.customer.com` | | Subject Alternative Names | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` | I certificati devono includere tutti i SAN per supportare la comunicazione TLS sicura tra lo Zoom Node e i moduli Zoom installati. **Requisiti dell'indirizzo IP** | Metrica | Valore / Descrizione | | ----------------------------- | ------------------------------------------------------ | | Indirizzi IP totali richiesti | 4 | | Strategia di condivisione IP | L'OS del Node condivide l'IP con il primo modulo (ZCP) | | IP individuali richiesti per | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Quando l'indirizzo IP è **condiviso** tra l'OS del Node e il primo modulo distribuito (ZCP), solo **quattro (4) indirizzi IP** sono necessari. Questo design ottimizza l'uso degli IP pur continuando a conformarsi agli standard di distribuzione. {% endhint %}
L'immagine sopra mostra una distribuzione ZPLS minima in cui il **OS del Node condivide il suo indirizzo IP con il modulo ZPLS installato**. Questo è il **unico scenario** nell'architettura Zoom Node in cui un **certificato TLS per host singolo** è valido. Il seguente nome host deve essere configurato nel DNS e incluso nel certificato TLS: * `zplsl.customer.com` **Mappatura funzionale dei nomi host** | Componente | Nome host | Ruolo del certificato TLS | Funzione | | ----------- | -------------------- | ------------------------- | ---------------------------------------- | | Modulo ZPLS | `zplsl.customer.com` | Common Name (CN) | Logica di Zoom Phone Local Survivability | **Configurazione del certificato TLS** | Campo | Valore | | ---------------- | ------------------- | | Common Name (CN) | `zcp1.customer.com` | | SANs | (non richiesto) | In questa configurazione, un certificato per host singolo è sufficiente poiché sia l'OS che il modulo ZPLS condividono lo stesso nome host e indirizzo IP. **Requisiti dell'indirizzo IP** | Metrica | Valore / Descrizione | | ----------------------------- | ---------------------------------------------------- | | Indirizzi IP totali richiesti | 1 | | Strategia di condivisione IP | OS del Node e ZPLS condividono un unico indirizzo IP | | Vincolo di distribuzione | Solo un modulo consentito per VM Node (solo ZPLS) | {% hint style="warning" %} ZPLS è l'unico scenario supportato nell'architettura Zoom Node in cui: * Un certificato per host singolo (solo CN) è accettabile * Per la distribuzione è richiesto solo un (1) indirizzo IP a causa della condivisione IP OS-modulo * La co-localizzazione di moduli aggiuntivi sulla stessa VM non è supportata {% endhint %} ### Decidi quale metodo di gestione dei certificati 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 presente nella lista di trust 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 sicura e il rinnovo dei certificati con Autorità di Certificazione (CA) pubblicamente attendibili. Zoom copre i costi associati alla registrazione e al rinnovo. * **Bring Your Own Certificate (BYOC)**: Con questa opzione, fornisci i tuoi certificati, firmati da qualsiasi importante CA pubblicamente attendibile. Gestisci tu la registrazione e i rinnovi dei certificati. Si applicano considerazioni aggiuntive riguardo alla possibilità per Zoom Node di avere fino a cinque nomi host/SAN quando si utilizzano certificati forniti dal cliente, come dettagliato più avanti. #### Gestione automatica dei certificati con Auto PKI Zoom Auto PKI installa automaticamente certificati CA pubblicamente attendibili validi per la piattaforma Zoom Node, così come per eventuali moduli distribuiti su di essa. Anche il rinnovo dei certificati è gestito automaticamente. Ciò semplifica la gestione dei certificati per tutti i servizi e per lo Zoom Node stesso. #### Comprendere la registrazione e il rinnovo dei certificati Auto PKI Lo scenario seguente può aiutarti a comprendere come funzionano la registrazione e il rinnovo dei certificati. Ad esempio: un amministratore ha distribuito una nuova istanza di 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 del modello**: Recupera tutti i modelli di configurazione supportati, incluse le opzioni per più provider CA, dal servizio Auto PKI nel cloud Zoom. 2. **Raccolta degli indirizzi IP**: Raccoglie tutti gli indirizzi 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 `..zoomonprem.com`. Questi domini sono configurati con record A/AAAA. 4. **Richiesta di nome DNS riservato**: Richiede un nome DNS riservato nel formato `rsvd-..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 del certificato**: Invia la Certificate Signing Request (CSR) al servizio Auto PKI nel cloud Zoom. Questo servizio collabora 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 sua corrispondente chiave privata (generata in precedenza) nello storage locale, rendendoli disponibili 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 rinnovi manuali. #### Bring Your Own Certificates (BYOC) Puoi installare i tuoi certificati validi e firmati pubblicamente su Zoom Node usando l'interfaccia web locale. Puoi farlo sia durante l'installazione iniziale sia in un momento successivo. Il processo sarà familiare a chi è abituato a installare certificati su applicazioni web. Se scegli di usare i tuoi certificati, ricorda che il certificato sarà su un server che comunica con più nomi host. Pertanto, il tipo di certificato che scegli deve supportare la crittografia per il traffico originato da più di un nome host (CN del certificato). Tutti i nomi host utilizzati per il Node e per eventuali servizi distribuiti devono essere risolvibili pubblicamente dai servizi cloud di Zoom. Zoom raccomanda due tipi di certificati: * **Certificato Wildcard** * **Certificato Multi-SAN** (conosciuto anche come certificato Multi-Domain, certificato SAN o certificato UCC) {% hint style="danger" %} Un tipico certificato per host singolo non funzionerà con Zoom Node, tranne nello scenario specifico in cui un singolo indirizzo IP e nome host sono condivisi tra Zoom Node e un singolo modulo. Per ulteriore contesto, vedi il diagramma ZPLS in [#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname](#option-2-zoom-meetings-hybrid-deployed-with-a-shared-ip-and-shared-hostname "mention") sezione. {% endhint %} **Certificati Wildcard: consigliati per semplicità** Un certificato wildcard può crittografare il traffico da qualsiasi nome host nel dominio. Per esempio: un certificato wildcard come \*.customer.com può crittografare il traffico da `host1.customer.com` che `host2.customer.com` o qualsiasi nome all'interno di `.customer.com`. Quando distribuisci Zoom Node e installi il certificato wildcard, esso crittograferà automaticamente il traffico per qualsiasi servizio che distribuisci sul Node con il requisito che tutti i servizi distribuiti utilizzino un Nome di Dominio Completamente Qualificato (FQDN) dal dominio wildcard. Questo minimizza lo sforzo per distribuire i servizi sul Node: non hai bisogno di 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** {% hint style="warning" %} Devi conoscere i nomi host e gli indirizzi IP che utilizzerai per il Node (fino a uno \[1]) e per eventuali Servizi che installerai (fino a quattro \[4]). **Queste informazioni sono richieste prima di registrare un certificato**. {% endhint %} Un certificato Multi-SAN è necessario per Zoom Node perché crittografa il traffico proveniente da cinque (5) nomi host. Una richiesta una tantum per questo certificato richiede la conoscenza preventiva di tutte le informazioni necessarie, inclusi i nomi dei Node pianificati 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 solo un SAN aggiuntivo per il nome host del servizio ZPLS. La tabella seguente 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 utilizzato in questo esempio) | (N/D) | Questo esempio è di una configurazione tipica, con un Node che ospita ZPLS sullo stesso IP più due servizi aggiuntivi su IP separati. Sostituisci “company.com” con il tuo dominio effettivo e usa gli indirizzi IP della tua rete. **Requisiti di risoluzione DNS** Zoom richiede che i nomi host siano risolvibili pubblicamente affinché possa essere stabilita una fiducia bidirezionale. Tutti i nomi host di Zoom Node e tutti i nomi host dei servizi distribuiti sui Node devono essere inclusi nella Zona DNS. Se la tua organizzazione gestisce servizi o domini DNS interni ed esterni separati, i nomi host di Zoom Node devono essere ospitati in una zona risolvibile dai tuoi server DNS esterni (possono essere limitati a risolvere solo per gli intervalli IP di Zoom). I tuoi utenti Zoom interni e il cloud Zoom devono comunicare utilizzando lo stesso insieme di nomi host.