# Considerações sobre a implementação do Zoom Node

Esta seção contém vários exemplos de como o Zoom Node pode dar suporte a vários Módulos de Serviço, como Zoom Meetings Hybrid e Zoom Phone Local Survivability (ZPLS). Implementações típicas com um endereço IP dedicado podem ter a seguinte coleção de diagramas.

Cada serviço implantado no Zoom Node requer um endereço IP exclusivo. Um Zoom Node terá até cinco (5) endereços IP atribuídos a ele se o Node tiver recebido um endereço específico para gerenciamento e um para cada serviço implantado (até quatro) no Node. Um Zoom Node executando um único serviço (como ZPLS) pode ser implantado com um único endereço IP se o Node e o serviço estiverem configurados para compartilhar o mesmo endereço IP.

Várias opções de implantação são mostradas abaixo. Observe o número de IPs e certificados (CN/SANs) para as várias opções de implantação.

### <mark style="color:azul;">Opção 1: Zoom Meetings Hybrid implantado com IPs dedicados e nomes de host</mark>

<figure><img src="https://1821044411-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-184792dfe5a78f13dbe0a8f67651f064fe826f21%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

A imagem acima resume os requisitos de configuração de IP e certificado para implantar **Zoom Meetings Hybrid** em ambientes locais ou de nuvem híbrida.

A tabela abaixo detalha o exemplo de Node e inclui seus Módulos de Serviço de proxy ativo e MMR:

| Componente                    | Nome do host         | Função do certificado TLS         | Função                              |
| ----------------------------- | -------------------- | --------------------------------- | ----------------------------------- |
| SO do nó                      | `node1.customer.com` | Nome Comum (CN)                   | Orquestração principal              |
| Proxy do Conector Zoom        | `zcp1.customer.com`  | Nome Alternativo do Assunto (SAN) | Sinalização e controle de sessão    |
| Roteador do Módulo de Mídia 1 | `mmr1.customer.com`  | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 2 | `mmr2.customer.com`  | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 3 | `mmr3.customer.com`  | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |

{% hint style="info" %}
Você deve Atribuir a cada módulo um endereço IP estático dedicado. Total de endereços IP necessários: cinco (5)
{% endhint %}

<figure><img src="https://1821044411-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-2edb7c64b83b0edaaf03d291a85d819051a8da00%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

A imagem acima descreve a configuração mínima necessária para implantar **Zoom Phone Survivability Local (ZPLS)**. O ZPLS permite a continuidade da disponibilidade do serviço telefônico em caso de interrupção da internet ou da nuvem, executando a lógica de sobrevivência localmente em uma VM do Zoom Node.

Os seguintes nomes de host devem ser configurados no DNS e incluídos no certificado TLS:

* `node1.customer.com`
* `zplsl.customer.com`

**Mapeamento Funcional de Nomes de Host**

| Componente  | Nome do host         | Função do certificado TLS   | Função                                      |
| ----------- | -------------------- | --------------------------- | ------------------------------------------- |
| SO do nó    | `node1.customer.com` | Nome Comum (CN)             | Orquestração principal                      |
| Módulo ZPLS | `zplsl.customer.com` | Nome Alternativo do Assunto | Lógica de Sobrevivência Local do Zoom Phone |

**Configuração do certificado TLS**

| Campo                         | Valor                |
| ----------------------------- | -------------------- |
| Nome Comum (CN)               | `node1.customer.com` |
| Nomes Alternativos do Sujeito | `zplsl.customer.com` |

Os certificados devem ser gerados ou obtidos (AC pública ou privada) para incluir tanto o CN quanto os SANs listados acima. Isso permite a validação TLS adequada para comunicação segura entre módulos.

**Requisitos de endereço IP**

| Métrica                           | Valor / Descrição                                 |
| --------------------------------- | ------------------------------------------------- |
| Total de endereços IP necessários | 5 (alocação geral)                                |
| Usado no contexto ZPLS            | 2 IPs (1 para o SO do Node, 1 para o módulo ZPLS) |

Embora sejam necessários cinco (5) IPs para a implementação geral, **apenas dois (2) endereços IP são usados ativamente** na implementação do ZPLS: um por módulo, a funcionar em um **VM Node dedicada**.

{% hint style="warning" %}
O ZPLS permite apenas um módulo por Node VM. Você não pode co-localizar o ZPLS com outros módulos Zoom na mesma VM.
{% endhint %}

Como estes diagramas se comparam? A primeira imagem mostra um exemplo de uma implantação híbrida do Zoom Meetings. A segunda imagem mostra um exemplo de uma implantação de sobrevivência local do Zoom Phone.

Você pode compartilhar o primeiro IP/nome de host entre o SO e o primeiro módulo, se desejar, para reduzir o número de endereços IP, nomes de host e Nomes Alternativos de Sujeito (SANs) necessários.

### <mark style="color:azul;">Opção 2: Zoom Meetings Hybrid implantado com um IP compartilhado e um nome de host compartilhado</mark>

<figure><img src="https://1821044411-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-6b1181f4394323c6364dc3dde2d10299e0000f9c%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

Esta configuração repete a estrutura de Node conforme vista no diagrama híbrido da Opção 1 do Zoom Meetings. No entanto, nesta implantação, o **O SO do nó partilha o seu endereço IP com o primeiro módulo implantado** (normalmente o Proxy do Zoom Conector, ZCP). Isso resulta em menor utilização de IP, mantendo o TLS e os requisitos funcionais.

Os seguintes nomes de host devem ser configurados no DNS e incluídos no certificado TLS:

* `zcp1.customer.com`
* `mmr1.customer.com`
* `mmr2.customer.com`
* `mmr3.customer.com`

**Mapeamento Funcional de Nomes de Host**

| Componente                    | Nome do host        | Função do certificado TLS         | Função                              |
| ----------------------------- | ------------------- | --------------------------------- | ----------------------------------- |
| ZCP (Proxy do Zoom Conector)  | `zcp1.customer.com` | Nome Comum (CN)                   | Sinalização e controle de sessão    |
| Roteador do Módulo de Mídia 1 | `mmr1.customer.com` | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 2 | `mmr2.customer.com` | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |
| Roteador do Módulo de Mídia 3 | `mmr3.customer.com` | Nome Alternativo do Assunto (SAN) | Roteamento e processamento de mídia |

**Configuração do certificado TLS**

| Campo                         | Valor                                                         |
| ----------------------------- | ------------------------------------------------------------- |
| Nome Comum (CN)               | `zcp1.customer.com`                                           |
| Nomes Alternativos do Sujeito | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` |

Os certificados devem incluir todos os SANs para Suporte à comunicação TLS segura entre o Zoom Node e os módulos Zoom instalados.

**Requisitos de endereço IP**

| Métrica                           | Valor / Descrição                                  |
| --------------------------------- | -------------------------------------------------- |
| Total de endereços IP necessários | 4                                                  |
| Estratégia de partilha de IP      | Node SO compartilha IP com o primeiro módulo (ZCP) |
| IPs individuais necessários para  | ZCP/MMR1, MMR2, MMR3                               |

{% hint style="info" %}
Quando o endereço IP estiver **partilhado** entre o SO do Node e o primeiro módulo implantado (ZCP), apenas **quatro (4) endereços IP** são necessários. Este design otimiza a utilização de IP, continuando a cumprir as normas de implementação.
{% endhint %}

<figure><img src="https://1821044411-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2Fgit-blob-043999f43a7b7f32d98af79cee7e29ca0d9b526e%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

A imagem acima mostra uma implementação mínima de ZPLS onde o **SO do Node partilha o seu endereço IP com o módulo ZPLS instalado**. Este é o **único cenário** na estrutura Zoom Node onde um **certificado TLS de anfitrião único** é válido.

O seguinte nome do anfitrião deve ser configurado no DNS e incluído no certificado TLS:

* `zplsl.customer.com`

**Mapeamento Funcional de Nomes de Host**

| Componente  | Nome do host         | Função do certificado TLS | Função                                      |
| ----------- | -------------------- | ------------------------- | ------------------------------------------- |
| Módulo ZPLS | `zplsl.customer.com` | Nome Comum (CN)           | Lógica de Sobrevivência Local do Zoom Phone |

**Configuração do certificado TLS**

| Campo           | Valor               |
| --------------- | ------------------- |
| Nome Comum (CN) | `zcp1.customer.com` |
| SANs            | (não é necessário)  |

Nesta configuração, um certificado de anfitrião único é suficiente, uma vez que tanto o SO quanto o módulo ZPLS compartilham o mesmo nome de anfitrião e endereço IP.

**Requisitos de endereço IP**

| Métrica                           | Valor / Descrição                                      |
| --------------------------------- | ------------------------------------------------------ |
| Total de endereços IP necessários | 1                                                      |
| Estratégia de partilha de IP      | O SO do nó e o ZPLS compartilham um único endereço IP  |
| Restrição de implementação        | Apenas um módulo permitido por VM do Nó (somente ZPLS) |

{% hint style="warning" %}
O ZPLS é o único cenário suportado na arquitetura do Zoom Node em que:

* Um certificado de anfitrião único (apenas CN) é aceitável
* Apenas um (1) endereço IP é necessário para a implementação devido ao compartilhamento de IP entre SO e módulo
* Não é suportada a co-localização de módulos adicionais na mesma VM
  {% endhint %}

### <mark style="color:azul;">Decida qual método de gerenciamento de certificado funciona melhor para suas implementações</mark>

Cada Módulo de Serviço implementado no Zoom Node requer um certificado válido assinado por uma Autoridade de Certificação (CA) publicamente confiável da lista de confiança de certificados do Zoom Node. Isto inclui autoridades públicas bem conhecidas.

O Zoom Node oferece dois métodos de gestão de certificados:

* **PKI Automática**: Esta solução inovadora automatiza a inscrição e renovação seguras de certificados com Autoridades de Certificação (CAs) publicamente confiáveis. O Zoom cobre os custos associados à inscrição e à renovação.
* **Traga o Seu Próprio certificado (BYOC)**: Com esta opção, fornece os seus próprios certificados, assinados por qualquer CA importante publicamente confiável. O utilizador trata da inscrição e das renovações dos certificados. Aplicam-se considerações adicionais relativamente ao potencial do Zoom Node para até cinco nomes de anfitrião/SANs ao utilizar certificados fornecidos pelo cliente, as quais são detalhadas mais abaixo.

#### Gestão Automática de certificados com PKI Automática

O Zoom Auto PKI instala automaticamente certificados de CA válidos e publicamente confiáveis para a plataforma Zoom Node, bem como para quaisquer módulos nela implementados. A renovação dos certificados também é tratada automaticamente. Isto simplifica a gestão de certificados para todos os serviços e para o próprio Zoom Node.

#### Compreender a Inscrição e a Renovação de certificados do Auto PKI

O cenário seguinte pode ajudá-lo a compreender como funciona a inscrição e a renovação de certificados.

Por exemplo: um administrador implantou uma nova instância do Node. Cada instância requer um certificado x509 válido. **A chave privada do certificado nunca deve sair desta instância**.

O processo Auto PKI executa os seguintes passos:

1. **Recuperação de template**: Recolhe todos os modelos de configuração compatíveis, incluindo opções para vários provedores de CA, do serviço Auto PKI na Zoom cloud.
2. **Coleta de endereço IP**: Reúne todos os endereços IP usados pelos serviços em execução no Node e os envia ao serviço Auto PKI no Zoom cloud.
3. **Provisionamento de nome DNS**: O serviço de nuvem Auto PKI retorna um conjunto de nomes DNS no formato `<instance_identificador>.<customer_identificador>.zoomonprem.com`. Esses domínios estão configurados com registos A/AAAA.
4. **Pedido de Nome DNS Reservado**: Solicita um nome DNS reservado no formato `rsvd-<randomized_string>.<customer_identificador>.zoomonprem.com`.
5. **Geração da solicitação de certificado**: Gera uma solicitação de certificado x509, usando os nomes DNS da terceira etapa no campo SAN e o nome reservado da quarta etapa no campo Common Name (CN).
6. **Emissão de certificado**: Envia a solicitação de assinatura de certificado (CSR) para o serviço Auto PKI no Zoom cloud. Esse serviço, em seguida, trabalha com fornecedores de CA para emitir o certificado, que inclui a lista SAN e o campo CN da etapa anterior.
7. **Armazenamento local**: Escreve o certificado x509 recém-emitido da última etapa e sua chave privada correspondente (gerada anteriormente) no armazenamento local, tornando-os disponíveis para serviços em execução na instância Node.

O Auto PKI simplifica a gestão de certificado no Zoom Node ao monitorizar automaticamente as datas de expiração e solicitar novos certificados, eliminando a necessidade de renovação manual.

#### Traga os Seus Próprios Certificados (BYOC)

Pode instalar os seus próprios certificados válidos, assinados publicamente, no Zoom Node utilizando a interface web local. Pode fazê-lo durante a instalação inicial ou posteriormente. O processo será familiar para quem está habituado a instalar certificados em aplicações baseadas na web.

Se optar por utilizar os seus próprios certificados, lembre-se de que o certificado estará num servidor que comunica com vários nomes de anfitrião. Por isso, o tipo de certificado que escolher deve suportar criptografia para tráfego com origem em mais de um nome de anfitrião (CN do certificado). Todos os nomes de anfitrião utilizados para o Node e quaisquer serviços implementados devem poder ser resolvidos publicamente pelos serviços de nuvem da Zoom.

A Zoom recomenda dois tipos de certificados:

* **Certificado wildcard**
* **Certificado Multi-SAN** (também conhecido como Certificado Multi-Domínio, Certificado SAN ou Certificado UCC)

{% hint style="danger" %}
Um certificado típico de anfitrião único não funcionará com o Zoom Node, exceto no cenário específico em que um único endereço IP e nome de anfitrião são partilhados entre o Zoom Node e um único módulo. Para contexto adicional, consulte o diagrama ZPLS na [#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") secção.
{% endhint %}

**Certificados curinga: recomendados pela simplicidade**

Um certificado curinga pode criptografar o tráfego de qualquer nome de host no domínio. Por exemplo: um certificado curinga como \*.customer.com pode criptografar o tráfego de `host1.customer.com` e `host2.customer.com` ou qualquer nome dentro de `.customer.com`.

Quando você implanta o Zoom Node e instala o certificado curinga, ele criptografará automaticamente o tráfego de quaisquer serviços que você implantar no Node, com a exigência de que todos os Serviços implantados usem um Nome de Domínio Totalmente Qualificado (FQDN) do domínio curinga.

Isso minimiza o esforço para implantar serviços no Node: você não precisa saber os nomes dos serviços antes de implantá-los. No entanto, você precisa saber os nomes dos serviços se estiver usando o método de certificado multi-SAN.

**Certificados Multi-SAN, Multi-Domínio, SAN ou UCC**

{% hint style="warning" %}
Você deve saber os nomes de host e os endereços IP que usará para o Zoom Node (até um \[1]) e quaisquer Serviços que você estará instalando (até quatro \[4]).

**Essas informações são necessárias antes de solicitar um certificado**.
{% endhint %}

Um certificado Multi-SAN é necessário para o Zoom Node porque ele criptografa o tráfego de cinco (5) nomes de host. Uma solicitação única para este certificado requer conhecimento prévio de todas as informações necessárias, incluindo os nomes planejados do Node e os nomes de todos os serviços previstos para implantação no Node. Por exemplo, com um módulo como o ZPLS, apenas um módulo ZPLS é implantado por Node, então é necessário apenas um SAN adicional para o nome de host do serviço ZPLS.

A tabela a seguir pode ser usada como exemplo:

| Nome de host (SAN)                    | Endereço 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` |
| (Serviço 4 - não usado neste exemplo) | (N/D)         |

Este exemplo é de uma configuração típica, com um nó a alojar o ZPLS no mesmo IP, além de dois serviços adicionais em IPs separados. Substitua “company.com” pelo seu domínio real e use os endereços IP da sua rede.

**Requisitos de Resolução de DNS**

O Zoom requer que os nomes de host sejam resolvíveis publicamente para que uma confiança bidirecional possa ser estabelecida. Todos os nomes de host do Zoom Node e todos os nomes de host de serviço implantados nos Nodes devem ser incluídos na Zona DNS.

Se a sua Organização executa serviços ou domínios de DNS internos e externos separados, os nomes de host do Zoom Node precisam ser hospedados em uma zona que possa ser resolvida pelos seus servidores de DNS externos (pode ser restrito para resolver apenas para intervalos de IP do Zoom). Os seus utilizadores internos do Zoom e a Zoom cloud precisam de comunicar usando o mesmo conjunto de nomes de host.