> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/sv/avancerade-enterprise-tjanster/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md).

# Överväganden vid distribution av Zoom Node

Detta avsnitt innehåller flera exempel på hur Zoom Node kan stödja olika servicemoduler 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 Node har tilldelats en specifik adress för hantering och en för varje distribuerad tjänst (upp till fyra) på Node. En Zoom Node som kör en enda tjänst (till exempel ZPLS) kan distribueras med en enda IP-adress om Node och tjänst tilldelas att dela samma IP-adress.

Flera distributionsalternativ visas nedan. Observera antalet IP:er och certifikat (CN/SAN:er) för de olika distributionsalternativen.

### <mark style="color:blå;">Alternativ 1: Zoom Meetings Hybrid distribuerat med dedikerade IP:er 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 eller hybrida molnmiljöer.

Tabellen nedan bryter ned exempel-noden och inkluderar dess aktiva proxy och MMR-servicemoduler:

| Komponent                     | Värdnamn             | Roll för TLS-certifikat         | Funktion                        |
| ----------------------------- | -------------------- | ------------------------------- | ------------------------------- |
| Node-operativsystem           | `node1.customer.com` | Gemensamt namn (CN)             | Kärnorkestrering                |
| Zoom anslutningsprogram Proxy | `zcp1.customer.com`  | Alternativt namn för ämne (SAN) | Signalering och sessionkontroll |
| Media Module Router 1         | `mmr1.customer.com`  | Alternativt namn för ämne (SAN) | Mediadirigering och bearbetning |
| Media Module Router 2         | `mmr2.customer.com`  | Alternativt namn för ämne (SAN) | Mediadirigering och bearbetning |
| Media Module Router 3         | `mmr3.customer.com`  | Alternativt namn för ämne (SAN) | Mediadirigering och bearbetning |

{% 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 beskriver den minsta konfiguration som krävs för att distribuera **Lokal överlevnadsfunktion för Zoom Phone (ZPLS)**. ZPLS möjliggör fortsatt tillgänglighet för telefontjänsten vid avbrott 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             | Roll för TLS-certifikat | Funktion                             |
| ------------------- | -------------------- | ----------------------- | ------------------------------------ |
| Node-operativsystem | `node1.customer.com` | Gemensamt namn (CN)     | Kärnorkestrering                     |
| ZPLS-modul          | `zplsl.customer.com` | Alternativt ämnesnamn   | Zoom Phone Local Survivability-logik |

**TLS-certifikatkonfiguration**

| Fält                  | Värde                |
| --------------------- | -------------------- |
| Gemensamt namn (CN)   | `node1.customer.com` |
| Alternativa ämnesnamn | `zplsl.customer.com` |

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

**Krav på IP-adress**

| Mätvärde                           | Värde / beskrivning                                       |
| ---------------------------------- | --------------------------------------------------------- |
| Totalt antal IP-adresser som krävs | 5 (allmän tilldelning)                                    |
| Används i ZPLS-sammanhang          | 2 IP:er (1 för Node-operativsystemet, 1 för ZPLS-modulen) |

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

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

Hur jämförs dessa diagram? Den första bilden visar ett exempel på en Zoom Meetings Hybrid-driftsättning. Den andra bilden visar ett exempel på en Zoom Phone Local Survivability-driftsättning.

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 (SAN:er) som krävs.

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

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

Denna konfiguration upprepar Node-strukturen som ses i diagrammet för Alternativ 1 Zoom Meetings Hybrid. Men i denna driftsättning, **Node-operativsystemet delar sin IP-adress med den första driftsatta modulen** (vanligtvis Zoom anslutningsprogram Proxy, ZCP). Detta resulterar i 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            | Roll för TLS-certifikat         | Funktion                        |
| ----------------------------------- | ------------------- | ------------------------------- | ------------------------------- |
| ZCP (Zoom anslutningsprogram Proxy) | `zcp1.customer.com` | Gemensamt namn (CN)             | Signalering och sessionkontroll |
| Media Module Router 1               | `mmr1.customer.com` | Alternativt namn för ämne (SAN) | Mediadirigering och bearbetning |
| Media Module Router 2               | `mmr2.customer.com` | Alternativt namn för ämne (SAN) | Mediadirigering och bearbetning |
| Media Module Router 3               | `mmr3.customer.com` | Alternativt namn för ämne (SAN) | Mediadirigering och bearbetning |

**TLS-certifikatkonfiguration**

| Fält                  | Värde                                                         |
| --------------------- | ------------------------------------------------------------- |
| Gemensamt namn (CN)   | `zcp1.customer.com`                                           |
| Alternativa ämnesnamn | `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ätvärde                           | Värde / beskrivning                                         |
| ---------------------------------- | ----------------------------------------------------------- |
| Totalt antal IP-adresser som krävs | 4                                                           |
| IP-delningsstrategi                | Node-operativsystemet delar IP 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 Node-operativsystemet och den första driftsatta modulen (ZCP), krävs endast **fyra (4) IP-adresser** Detta upplägg optimerar användningen av IP-adresser samtidigt som det fortfarande följer distributionsstandarderna.
{% endhint %}

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

Bilden ovan visar en minimal ZPLS-driftsättning 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 enda 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             | Roll för TLS-certifikat | Funktion                             |
| ---------- | -------------------- | ----------------------- | ------------------------------------ |
| ZPLS-modul | `zplsl.customer.com` | Gemensamt namn (CN)     | Zoom Phone Local Survivability-logik |

**TLS-certifikatkonfiguration**

| Fält                | Värde               |
| ------------------- | ------------------- |
| Gemensamt namn (CN) | `zcp1.customer.com` |
| SAN:er              | (krävs inte)        |

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ätvärde                           | Värde / beskrivning                                    |
| ---------------------------------- | ------------------------------------------------------ |
| Totalt antal IP-adresser som krävs | 1                                                      |
| IP-delningsstrategi                | 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 scenario som stöds i Zoom Node-arkitekturen där:

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

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

Varje servicemodul som driftsätts på Zoom Node kräver ett giltigt certifikat signerat av en allmänt betrodd certifikatutfärdare (CA) från Zoom Nodes lista över betrodda certifikat. Detta inkluderar välkända offentliga utfärdare.

Zoom Node erbjuder två metoder för certifikathantering:

* **Auto PKI**: Denna innovativa lösning automatiserar säker certifikatutfärdning och förnyelse med allmänt betrodda certifikatutfärdare (CA). Zoom står för kostnaderna i samband med utfärdande och förnyelse.
* **Ta med ditt eget certifikat (BYOC)**: Med detta alternativ tillhandahåller du dina egna certifikat, signerade av en större allmänt betrodd CA. Du hanterar certifikatutfärdande och förnyelser. Ytterligare överväganden gäller för Zoom Nodes potentiella upp till fem värdnamn/SAN:er när kundtillhandahållna certifikat används, vilket beskrivs mer nedan.

#### Automatisk certifikathantering med Auto PKI

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

#### Förstå certifikatutfärdande och förnyelse med Auto PKI

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

Till exempel: En administratör har driftsatt 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. **Hämtning av mallar**: Hämtar alla konfigurationsmallar som stöds, inklusive alternativ för flera CA-leverantörer, från Auto PKI-tjänsten i Zoom-moln.
2. **Insamling av IP-adresser**: Samlar in alla IP-adresser som används av tjänster som körs på noden och skickar dem till Auto PKI-tjänsten i Zoom-moln.
3. **Etablering av DNS-namn**: Auto PKI-molntjänsten returnerar en uppsättning DNS-namn i formatet `<instance_identifierare>.<customer_identifierare>.zoomonprem.com`. Dessa domäner konfigureras 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-certifikatförfrågan, med hjälp av DNS-namnen från det tredje steget i SAN-fältet och det reserverade namnet från det fjärde steget i fältet Common Name (CN).
6. **Utfärdande av certifikat**: Skickar certifikatsigneringsbegäran (CSR) till Auto PKI-tjänsten i Zoom-moln. Denna tjänst arbetar 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 senaste steget och dess motsvarande privata nyckel (genererad tidigare) till lokal lagring, vilket gör dem tillgänglig för tjänster som körs på Node-instansen.

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

#### Ta med egna certifikat (BYOC)

Du kan installera dina egna giltiga, publikt 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 eventuella distribuerade tjänster måste vara offentligt upplösningsbara av Zooms molntjänster.

Zoom rekommenderar två typer av certifikat:

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

{% hint style="danger" %}
Ett vanligt certifikat för en enda värd kommer inte att fungera 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 enskild 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 enkelhetens skull**

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

När du distribuerar Zoom Node och installerar wildcard-certifikatet kommer det automatiskt att kryptera trafiken för alla tjänster du distribuerar på noden, under förutsättning att alla distribuerade tjänster använder ett fullständigt 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 namnen på tjänsterna innan du distribuerar dem. Däremot behöver du 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 värdnamnen och IP-adresserna du kommer att använda för noden (upp till ett \[1]) och alla tjänster som du kommer att installera (upp till fyra \[4]).

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

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

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 det här exemplet) | (Ej tillämpligt) |

Det här exemplet är en typisk konfiguration, med en nod som hostar ZPLS på samma IP samt 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-upplösning**

Zoom kräver att värdnamnen kan lösas offentligt så att ömsesidigt förtroende kan etableras. Alla Zoom Node-värdnamn och alla tjänstvärdnamn som distribueras på noderna måste ingå i DNS-zonen.

Om din organisation kör separata interna och externa DNS-tjänster eller domäner måste värdnamnen för Zoom Node vara hostade i en zon som kan lösas upp av dina externa DNS-servrar (kan begränsas till att endast lösas upp för Zooms IP-intervall). Dina interna Zoom-användare och Zoom-moln behöver kommunicera med hjälp av samma uppsättning värdnamn.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` 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>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.