# Överväganden för distribution av Zoom Node

Detta avsnitt innehåller flera exempel på hur Zoom Node kan stödja olika tjänstemoduler som Zoom Meetings Hybrid och Zoom Phone Local Survivability (ZPLS). Typiska distributioner med en dedikerad IP-adress kan se ut som följande samling diagram.

Varje tjänst som distribueras på Zoom Node kräver en unik IP-adress. En Zoom Node kan ha upp till fem (5) IP-adresser tilldelade om noden har tilldelats en specifik adress för hantering och en för varje tjänst som distribueras (upp till fyra) på noden. En Zoom Node som kör en enda tjänst (till exempel ZPLS) kan distribueras med en enda IP-adress om noden och tjänsten har tilldelats att dela samma IP-adress.

Flera distributionsalternativ visas nedan. Observera antalet IP-adresser och certifikat (CN/SANs) för de olika distributionsalternativen.

### <mark style="color:blå;">Alternativ 1: Zoom Meetings Hybrid distribuerat med dedikerade IP-adresser och värdnamn</mark>

<figure><img src="/files/fb944829fbd7302bed2c76c46975a8787d8c3dc6" alt=""><figcaption></figcaption></figure>

Bilden ovan sammanfattar kraven på IP- och certifikatkonfiguration för att distribuera **Zoom Meetings Hybrid** i lokala miljöer eller hybrida molnmiljöer.

Tabellen nedan beskriver exempel-noden och inkluderar dess aktiv proxy och MMR-tjänstemoduler:

| Komponent                    | Värdnamn             | TLS certifikatroll             | Funktion                            |
| ---------------------------- | -------------------- | ------------------------------ | ----------------------------------- |
| Node operativsystem          | `node1.customer.com` | Common Name (CN)               | Kärnorkestrering                    |
| Zoom anslutningsprogramproxy | `zcp1.customer.com`  | Subject Alternative Name (SAN) | Signalering och sessionkontroll     |
| Mediamodulrouter 1           | `mmr1.customer.com`  | Subject Alternative Name (SAN) | Dirigering och bearbetning av media |
| Mediamodulrouter 2           | `mmr2.customer.com`  | Subject Alternative Name (SAN) | Dirigering och bearbetning av media |
| Mediamodulrouter 3           | `mmr3.customer.com`  | Subject Alternative Name (SAN) | Dirigering och bearbetning av media |

{% hint style="info" %}
Du måste tilldela varje modul en dedikerad statisk IP-adress. Totalt antal IP-adresser som krävs: fem (5)
{% endhint %}

<figure><img src="/files/6605a3e7bd3446c01cc623c40f3dad14de25341a" alt=""><figcaption></figcaption></figure>

Bilden ovan visar den minimikonfiguration som krävs för att distribuera **Zoom Phone Lokal överlevnadsförmåga (ZPLS)**. ZPLS möjliggör fortsatt tillgänglighet för telefontjänsten i händelse av störningar i internet eller moln genom att köra överlevnadslogik lokalt på en Zoom Node VM.

Följande värdnamn måste konfigureras i DNS och inkluderas i TLS-certifikatet:

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

**Funktionell mappning av värdnamn**

| Komponent           | Värdnamn             | TLS certifikatroll        | Funktion                             |
| ------------------- | -------------------- | ------------------------- | ------------------------------------ |
| Node operativsystem | `node1.customer.com` | Common Name (CN)          | Kärnorkestrering                     |
| ZPLS-modul          | `zplsl.customer.com` | Alternativt namn för ämne | Zoom Phone Local Survivability-logik |

**Konfiguration av TLS-certifikat**

| Fält                      | Värde                |
| ------------------------- | -------------------- |
| Common Name (CN)          | `node1.customer.com` |
| Alternativa namn för ämne | `zplsl.customer.com` |

Certifikat måste genereras eller införskaffas (offentlig eller privat CA) för att inkludera både CN och de SAN:er som anges ovan. Detta möjliggör korrekt TLS-validering för säker kommunikation mellan moduler.

**Krav på IP-adress**

| Mått                               | Värde / Beskrivning                                             |
| ---------------------------------- | --------------------------------------------------------------- |
| Totalt antal IP-adresser som krävs | 5 (allmän tilldelning)                                          |
| Används i ZPLS-kontext             | 2 IP-adresser (1 för nodens operativsystem, 1 för ZPLS-modulen) |

Medan fem (5) IP-adresser krävs för allmän distribution, **endast två (2) IP-adresser används aktivt** i ZPLS-distributionen: en per modul, körande på en **dedikerad Node VM**.

{% hint style="warning" %}
ZPLS tillåter endast en modul per Node VM. Du kan inte samplacera ZPLS med andra Zoom-moduler på samma VM.
{% endhint %}

Hur jämför dessa diagram? Den första bilden visar ett exempel på en hybriddistribution av Zoom Meetings. Den andra bilden visar ett exempel på en distribution av Zoom Phone Local Survivability.

Du kan dela den första IP-adressen/värdnamnet mellan operativsystemet och den första modulen, om så önskas, för att minska antalet IP-adresser, värdnamn och Subject Alternative Names (SANs) som krävs.

### <mark style="color:blå;">Alternativ 2: Zoom Meetings Hybrid distribuerat med en delad IP-adress och ett delat värdnamn</mark>

<figure><img src="/files/5b8d3f31555c43c0fe4d314b819efaab1dab8c07" alt=""><figcaption></figcaption></figure>

Den här konfigurationen upprepar Node-strukturen som i diagrammet för Zoom Meetings Hybrid i alternativ 1. Men i den här distributionen, **Node-operativsystemet delar sin IP-adress med den först distribuerade modulen** (vanligtvis Zoom anslutningsprogram Proxy, ZCP). Detta leder till minskad IP-användning samtidigt som TLS- och funktionskraven upprätthålls.

Följande värdnamn måste konfigureras i DNS och inkluderas i TLS-certifikatet:

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

**Funktionell mappning av värdnamn**

| Komponent                           | Värdnamn            | TLS certifikatroll             | Funktion                            |
| ----------------------------------- | ------------------- | ------------------------------ | ----------------------------------- |
| ZCP (Zoom Anslutningsprogram Proxy) | `zcp1.customer.com` | Common Name (CN)               | Signalering och sessionkontroll     |
| Mediamodulrouter 1                  | `mmr1.customer.com` | Subject Alternative Name (SAN) | Dirigering och bearbetning av media |
| Mediamodulrouter 2                  | `mmr2.customer.com` | Subject Alternative Name (SAN) | Dirigering och bearbetning av media |
| Mediamodulrouter 3                  | `mmr3.customer.com` | Subject Alternative Name (SAN) | Dirigering och bearbetning av media |

**Konfiguration av TLS-certifikat**

| Fält                      | Värde                                                         |
| ------------------------- | ------------------------------------------------------------- |
| Common Name (CN)          | `zcp1.customer.com`                                           |
| Alternativa namn för ämne | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` |

Certifikat måste inkludera alla SAN:er för att stödja säker TLS-kommunikation mellan Zoom Node och de installerade Zoom-modulerna.

**Krav på IP-adress**

| Mått                               | Värde / Beskrivning                                                    |
| ---------------------------------- | ---------------------------------------------------------------------- |
| Totalt antal IP-adresser som krävs | 4                                                                      |
| Strategi för IP-delning            | Operativsystemet på noden delar IP-adress med den första modulen (ZCP) |
| Individuella IP-adresser krävs för | ZCP/MMR1, MMR2, MMR3                                                   |

{% hint style="info" %}
När IP-adressen är **delad** mellan operativsystemet på noden och den första distribuerade modulen (ZCP), endast **fyra (4) IP-adresser** krävs. Denna design optimerar användningen av IP samtidigt som den fortfarande uppfyller distributionsstandarderna.
{% endhint %}

<figure><img src="/files/0c77af23fecd4e154013fe5ec6ee853a4e670558" alt=""><figcaption></figcaption></figure>

Bilden ovan visar en minimal ZPLS-distribution där **Node-operativsystemet delar sin IP-adress med den installerade ZPLS-modulen**. Detta är det **enda scenariot** i Zoom Node-ramverket där ett **TLS-certifikat för en enskild värd** är giltigt.

Följande värdnamn måste konfigureras i DNS och inkluderas i TLS-certifikatet:

* `zplsl.customer.com`

**Funktionell mappning av värdnamn**

| Komponent  | Värdnamn             | TLS certifikatroll | Funktion                             |
| ---------- | -------------------- | ------------------ | ------------------------------------ |
| ZPLS-modul | `zplsl.customer.com` | Common Name (CN)   | Zoom Phone Local Survivability-logik |

**Konfiguration av TLS-certifikat**

| Fält             | Värde                |
| ---------------- | -------------------- |
| Common Name (CN) | `zcp1.customer.com`  |
| SAN:er           | (inte obligatoriskt) |

I denna konfiguration räcker ett certifikat för en enda värd eftersom både operativsystemet och ZPLS-modulen delar samma värdnamn och IP-adress.

**Krav på IP-adress**

| Mått                               | Värde / Beskrivning                                    |
| ---------------------------------- | ------------------------------------------------------ |
| Totalt antal IP-adresser som krävs | 1                                                      |
| Strategi för IP-delning            | Node-operativsystemet och ZPLS delar en enda IP-adress |
| Driftsättningsbegränsning          | Endast en modul tillåts per Node VM (endast ZPLS)      |

{% hint style="warning" %}
ZPLS är det enda stödda scenariot i Zoom Node-arkitekturen där:

* Ett certifikat för en enda värd (endast CN) är godtagbart
* Endast en (1) IP-adress krävs för driftsättning på grund av IP-delning mellan operativsystem och modul
* Samlokalisering av ytterligare moduler på samma VM stöds inte
  {% endhint %}

### <mark style="color:blå;">Bestäm vilken metod för certifikathantering som fungerar bäst för dina driftsättningar</mark>

Varje tjänstemodul som distribueras på Zoom Node kräver ett giltigt certifikat signerat av en offentligt betrodd certifikatutfärdare (CA) från Zoom Node:s lista över betrodda certifikat. Detta inkluderar välkända offentliga myndigheter.

Zoom Node erbjuder två certifikathanteringsmetoder:

* **Automatisk PKI**: Denna innovativa lösning automatiserar säker registrering och förnyelse av certifikat med allmänt betrodda certifikatutfärdare (CA:er). Zoom täcker kostnaderna som är kopplade till registrering och förnyelse.
* **Ta med ditt eget certifikat (BYOC)**: Med det här alternativet tillhandahåller du dina egna certifikat, signerade av en valfri större offentligt betrodd CA. Du hanterar certifikatsregistrering och förnyelser. Ytterligare överväganden gäller för Zoom Node:s potentiella stöd för upp till fem värdnamn/SAN:er när kundtillhandahållna certifikat används, vilket beskrivs närmare nedan.

#### Automatisk certifikathantering med Auto PKI

Zoom Auto PKI installerar giltiga, offentligt betrodda CA-certifikat automatiskt för Zoom Node-plattformen, samt alla moduler som distribueras på den. Certifikatförnyelse hanteras också automatiskt. Detta förenklar certifikathanteringen för alla tjänster och själva Zoom Node.

#### Förstå automatisk PKI-certifikatregistrering och förnyelse

Följande scenario kan hjälpa dig att förstå hur certifikatregistrering och förnyelse fungerar.

Till exempel: En administratör har distribuerat en ny Node-instans. Varje instans kräver ett giltigt x509-certifikat. **Certifikatets privata nyckel får aldrig lämna denna instans**.

Auto PKI-processen utför följande steg:

1. **Mallhämtning**: Hämtar alla stödda konfigurationsmallar, inklusive alternativ för flera CA-leverantörer, från Auto PKI-tjänsten i Zoom-molnet.
2. **IP-adressinsamling**: Samlar in alla IP-adresser som används av tjänster som körs på Nod och skickar dem till Auto PKI-tjänsten i Zoom-molnet.
3. **DNS-namnförsörjning**: Auto PKI-molntjänsten returnerar en uppsättning DNS-namn i formatet `<instans_identifierare>.<kund_identifierare>.zoomonprem.com`. Dessa domäner är konfigurerade med A/AAAA-poster.
4. **Begäran om reserverat DNS-namn**: Begär ett reserverat DNS-namn i formatet `rsvd-<randomized_string>.<customer_identifierare>.zoomonprem.com`.
5. **Generering av certifikatbegäran**: Genererar en x509-certifikatbegäran, med DNS-namnen från det tredje steget i SAN-fältet och det reserverade namnet från det fjärde steget i Common Name (CN)-fältet.
6. **Utfärdande av certifikat**: Skickar certifikatsigneringsbegäran (CSR) till Auto PKI-tjänsten i Zoom-moln. Denna tjänst samarbetar sedan med CA-leverantörer för att utfärda certifikatet, vilket inkluderar SAN-listan och CN-fältet från föregående steg.
7. **Lokal lagring**: Skriver det nyligen utfärdade x509-certifikatet från det sista steget och dess motsvarande privata nyckel (som genererades tidigare) till lokal lagring, så att de blir tillgängliga för tjänster som körs på Node-instansen.

Auto PKI förenklar hanteringen av certifikat på Zoom Node genom att automatiskt övervaka utgångsdatum och begära nya certifikat, vilket eliminerar behovet av manuell förnyelse.

#### Ta med dina egna certifikat (BYOC)

Du kan installera dina egna giltiga, offentligt signerade certifikat på Zoom Node med hjälp av det lokala webbgränssnittet. Du kan göra detta antingen under den första installationen eller vid ett senare tillfälle. Processen kommer att vara bekant för dem som är vana vid att installera certifikat i webbaserade applikationer.

Om du väljer att använda dina egna certifikat, kom ihåg att certifikatet kommer att finnas på en server som kommunicerar med flera värdnamn. Därför måste den certifikattyp du väljer stödja kryptering för trafik som kommer från mer än ett värdnamn (certifikatets CN). Alla värdnamn som används för Node och alla distribuerade tjänster måste vara offentligt upplösbara av Zooms molntjänster.

Zoom rekommenderar två typer av certifikat:

* **Jokerteckencertifikat**
* **Multi-SAN-certifikat** (även känt som Multi-Domain-certifikat, SAN-certifikat eller UCC-certifikat)

{% hint style="danger" %}
Ett typiskt certifikat för en enda värd fungerar inte med Zoom Node, förutom i det specifika scenariot där en enda IP-adress och ett värdnamn delas mellan Zoom Node och en enda modul. För ytterligare sammanhang, se ZPLS-diagrammet i [#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") avsnittet.
{% endhint %}

**Wildcard-certifikat: Rekommenderas för enkelhet**

Ett wildcard-certifikat kan kryptera trafik från valfritt värdnamn i domänen. Till exempel: Ett wildcard-certifikat som \*.customer.com kan kryptera trafik från `host1.customer.com` och `host2.customer.com` eller vilket namn som helst inom `.customer.com`.

När du distribuerar Zoom Node och installerar wildcard-certifikatet krypterar det automatiskt trafik för alla tjänster du distribuerar på noden, med kravet att alla distribuerade tjänster använder ett Fullständigt kvalificerat domännamn (FQDN) från wildcard-domänen.

Detta minimerar arbetet med att distribuera tjänster på noden: du behöver inte känna till tjänsternas namn innan du distribuerar dem. Du behöver dock känna till tjänsternas namn om du använder metoden med multi-SAN-certifikat.

**Multi-SAN-, Multi-Domain-, SAN- eller UCC-certifikat**

{% hint style="warning" %}
Du måste känna till de värdnamn och IP-adresser som du kommer att använda för Node (upp till en \[1]) och alla tjänster som du kommer att installera (upp till fyra \[4]).

**Denna information krävs innan ett certifikat registreras**.
{% endhint %}

Ett Multi-SAN-certifikat är nödvändigt för Zoom Node eftersom det krypterar trafik från fem (5) värdnamn. En engångsbegäran för detta certifikat kräver förhandskännedom om all nödvändig information, inklusive planerade Node-namn och namnen på alla tjänster som är planerade för driftsättning på Node. Till exempel, med en modul som ZPLS, driftsätts endast en ZPLS-modul per Node, så endast ett ytterligare SAN behövs för ZPLS-tjänstens värdnamn.

Följande tabell kan användas som ett exempel:

| Värdnamn (SAN)                            | IP-adress        |
| ----------------------------------------- | ---------------- |
| `zoom-node01.company.com`                 | `10.1.50.100`    |
| `zpls.company.com`                        | `10.1.50.100`    |
| `zoom-recording.company.com`              | `10.1.50.101`    |
| `zoom-webbinarium.company.com`            | `10.1.50.102`    |
| (Tjänst 4 - används inte i detta exempel) | (Ej tillämpligt) |

Detta exempel är en typisk konfiguration, med en Node som är värd för ZPLS på samma IP plus två ytterligare tjänster på separata IP-adresser. Ersätt “company.com” med din faktiska domän och använd ditt nätverks IP-adresser.

**Krav på DNS-uppslagning**

Zoom kräver att värdnamnen kan slås upp offentligt så att ömsesidigt förtroende i båda riktningar kan upprättas. Alla Zoom Node-värdnamn och alla tjänstvärdnamn som distribueras på Node:arna måste ingå i DNS-zonen.

Om din organisation använder separata interna och externa DNS-tjänster eller domäner, behöver Zoom Node-värdnamnen vara värdar i en zon som kan slås upp av dina externa DNS-servrar (kan begränsas till att endast slå upp för Zoom-IP-intervall). Dina interna Zoom-användare och Zoom-moln behöver kommunicera med samma uppsättning värdnamn.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://library.zoom.com/technical-library/sv/avancerade-enterprise-tjanster/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.