> 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/nl/geavanceerde-diensten-voor-onderneming/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md). # Implementatieoverwegingen voor Zoom Node Deze sectie bevat verschillende voorbeelden van hoe Zoom Node verschillende Service Modules kan ondersteunen, zoals Zoom Meetings Hybrid en Zoom Phone Local Survivability (ZPLS). Typische implementaties met een toegewijd IP-adres kunnen eruitzien als de volgende verzameling diagrammen. Elke service die op Zoom Node wordt geïmplementeerd, vereist een uniek IP-adres. Een Zoom Node heeft tot vijf (5) IP-adressen toegewezen als aan de Node een specifiek adres voor beheer is toegewezen en één voor elke geïmplementeerde service (maximaal vier) op de Node. Een Zoom Node waarop één enkele service draait (zoals ZPLS) kan worden geïmplementeerd met één IP-adres als de Node en de service zijn toegewezen om hetzelfde IP-adres te delen. Hieronder worden verschillende implementatieopties getoond. Let op het aantal IP-adressen en certificaten (CN/SAN's) voor de verschillende implementatieopties. ### Optie 1: Zoom Meetings Hybrid geïmplementeerd met toegewezen IP-adressen en hostnamen
Deze afbeelding hierboven vat de vereisten voor IP- en certificaatconfiguratie samen voor het implementeren van **Zoom Meetings Hybrid** in on-premises of hybride Cloud-omgevingen. De onderstaande tabel splitst de voorbeeld-Node uit en bevat de actieve proxy- en MMR-Service Modules: | Component | Hostnaam | Rol van TLS-certificaat | Functie | | ---------------------- | -------------------- | ------------------------------ | --------------------------------- | | Node Besturingssysteem | `node1.customer.com` | Common Name (CN) | Kernorkestratie | | Zoom Connector Proxy | `zcp1.customer.com` | Subject Alternative Name (SAN) | Signalering en sessiecontrole | | Media Module Router 1 | `mmr1.customer.com` | Subject Alternative Name (SAN) | Routering en verwerking van media | | Media Module Router 2 | `mmr2.customer.com` | Subject Alternative Name (SAN) | Routering en verwerking van media | | Media Module Router 3 | `mmr3.customer.com` | Subject Alternative Name (SAN) | Routering en verwerking van media | {% hint style="info" %} U moet aan elke module een toegewezen statisch IP-adres geven. Totaal vereiste IP-adressen: vijf (5) {% endhint %}
De bovenstaande afbeelding schetst de minimale configuratie die nodig is om **Zoom Phone Local Survivability (ZPLS)**. ZPLS maakt het mogelijk de beschikbaarheid van de telefoonservice voort te zetten in geval van internet- of Cloud-verstoring door survivability-logica lokaal uit te voeren op een Zoom Node-VM. De volgende hostnamen moeten in DNS worden geconfigureerd en in het TLS-certificaat worden opgenomen: * `node1.customer.com` * `zplsl.customer.com` **Functionele mapping van hostnamen** | Component | Hostnaam | Rol van TLS-certificaat | Functie | | ---------------------- | -------------------- | ------------------------ | ------------------------------------- | | Node Besturingssysteem | `node1.customer.com` | Common Name (CN) | Kernorkestratie | | ZPLS-module | `zplsl.customer.com` | Subject Alternative Name | Zoom Phone Local Survivability-logica | **TLS-certificaatconfiguratie** | Veld | Waarde | | ------------------------- | -------------------- | | Common Name (CN) | `node1.customer.com` | | Subject Alternative Names | `zplsl.customer.com` | Certificaten moeten worden gegenereerd of aangeschaft (publieke of private CA) om zowel de hierboven vermelde CN als SAN's op te nemen. Dit maakt correcte TLS-validatie mogelijk voor veilige communicatie tussen modules. **Vereisten voor IP-adressen** | Metriek | Waarde / Beschrijving | | --------------------------- | ----------------------------------------------------------------- | | Totaal vereiste IP-adressen | 5 (algemene toewijzing) | | Gebruikt in ZPLS-context | 2 IP-adressen (1 voor Node Besturingssysteem, 1 voor ZPLS-module) | Hoewel vijf (5) IP-adressen vereist zijn voor algemene implementatie, **slechts twee (2) IP-adressen worden actief gebruikt** in de ZPLS-implementatie: één per module, draaiend op een **dedicated Node-VM**. {% hint style="warning" %} ZPLS staat slechts één module per Node-VM toe. U kunt ZPLS niet op dezelfde VM naast andere Zoom-modules plaatsen. {% endhint %} Hoe verhouden deze diagrammen zich tot elkaar? De eerste afbeelding toont een voorbeeld van een Zoom Meetings Hybrid-implementatie. De tweede afbeelding toont een voorbeeld van een Zoom Phone Local Survivability-implementatie. U kunt desgewenst de eerste IP/hostnaam delen tussen het Besturingssysteem en de eerste module, om het aantal vereiste IP-adressen, hostnamen en Subject Alternative Names (SANs) te verminderen. ### Optie 2: Zoom Meetings Hybrid geïmplementeerd met een gedeeld IP en gedeelde hostnaam
Deze configuratie herhaalt de Node-structuur zoals te zien in het Zoom Meetings Hybrid-diagram van Optie 1. In deze implementatie echter, de **Het Node-Besturingssysteem deelt zijn IP-adres met de eerst geïmplementeerde module** (meestal de Zoom Connector Proxy, ZCP). Dit resulteert in een lager IP-gebruik, terwijl TLS en functionele vereisten behouden blijven. De volgende hostnamen moeten in DNS worden geconfigureerd en in het TLS-certificaat worden opgenomen: * `zcp1.customer.com` * `mmr1.customer.com` * `mmr2.customer.com` * `mmr3.customer.com` **Functionele mapping van hostnamen** | Component | Hostnaam | Rol van TLS-certificaat | Functie | | -------------------------- | ------------------- | ------------------------------ | --------------------------------- | | ZCP (Zoom Connector Proxy) | `zcp1.customer.com` | Common Name (CN) | Signalering en sessiecontrole | | Media Module Router 1 | `mmr1.customer.com` | Subject Alternative Name (SAN) | Routering en verwerking van media | | Media Module Router 2 | `mmr2.customer.com` | Subject Alternative Name (SAN) | Routering en verwerking van media | | Media Module Router 3 | `mmr3.customer.com` | Subject Alternative Name (SAN) | Routering en verwerking van media | **TLS-certificaatconfiguratie** | Veld | Waarde | | ------------------------- | ------------------------------------------------------------- | | Common Name (CN) | `zcp1.customer.com` | | Subject Alternative Names | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` | Certificaten moeten alle SAN's bevatten om beveiligde TLS-communicatie tussen de Zoom Node en de geïnstalleerde Zoom-modules te ondersteunen. **Vereisten voor IP-adressen** | Metriek | Waarde / Beschrijving | | -------------------------------------- | ----------------------------------------------------------------- | | Totaal vereiste IP-adressen | 4 | | Strategie voor IP-deling | Besturingssysteem van de node deelt IP met de eerste module (ZCP) | | Afzonderlijke IP-adressen vereist voor | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Wanneer het IP-adres **gedeeld** tussen het Besturingssysteem van de node en de eerste geïmplementeerde module (ZCP), alleen **vier (4) IP-adressen** zijn vereist. Dit ontwerp optimaliseert het IP-gebruik en voldoet daarbij nog steeds aan de implementatiestandaarden. {% endhint %}
De bovenstaande afbeelding toont een minimale ZPLS-implementatie waarbij de **Besturingssysteem van Node deelt zijn IP-adres met de geïnstalleerde ZPLS-module**. Dit is het **enige scenario** in het Zoom Node-framework waarin een **enkelhost-TLS-certificaat** geldig is. De volgende hostnaam moet in DNS worden geconfigureerd en worden opgenomen in het TLS-certificaat: * `zplsl.customer.com` **Functionele mapping van hostnamen** | Component | Hostnaam | Rol van TLS-certificaat | Functie | | ----------- | -------------------- | ----------------------- | ------------------------------------- | | ZPLS-module | `zplsl.customer.com` | Common Name (CN) | Zoom Phone Local Survivability-logica | **TLS-certificaatconfiguratie** | Veld | Waarde | | ---------------- | ------------------- | | Common Name (CN) | `zcp1.customer.com` | | SAN's | (niet vereist) | In deze configuratie is een certificaat voor één host voldoende, aangezien zowel het Besturingssysteem als de ZPLS-module dezelfde hostnaam en hetzelfde IP-adres delen. **Vereisten voor IP-adressen** | Metriek | Waarde / Beschrijving | | --------------------------- | ------------------------------------------------------- | | Totaal vereiste IP-adressen | 1 | | Strategie voor IP-deling | Node Besturingssysteem en ZPLS delen één IP-adres | | Implementatiebeperking | Slechts één module toegestaan per Node VM (alleen ZPLS) | {% hint style="warning" %} ZPLS is het enige ondersteunde scenario in de Zoom Node-architectuur waarbij: * Een certificaat voor één host (alleen CN) is acceptabel * Voor implementatie is slechts één (1) IP-adres vereist vanwege het delen van IP tussen Besturingssysteem en module * Co-locatie van დამატitional modules op dezelfde VM wordt niet ondersteund {% endhint %} ### Bepaal welke methode voor certificaatbeheer het beste werkt voor uw implementaties Elke servicemodule die op Zoom Node is geïmplementeerd, vereist een geldig certificaat dat is ondertekend door een openbaar vertrouwde certificaatautoriteit (CA) uit de certificaat-vertrouwenslijst van Zoom Node. Dit omvat bekende openbare autoriteiten. Zoom Node biedt twee methoden voor certificaatbeheer: * **Auto PKI**: Deze innovatieve oplossing automatiseert de veilige certificaatinschrijving en -vernieuwing bij openbaar vertrouwde certificaatautoriteiten (CA's). Zoom dekt de kosten die gepaard gaan met inschrijving en vernieuwing. * **Breng uw eigen certificaat mee (BYOC)**: Met deze optie levert u uw eigen certificaten, ondertekend door een grote openbaar vertrouwde CA. U verzorgt de certificaatinschrijving en vernieuwingen. Er gelden aanvullende overwegingen met betrekking tot het potentieel van Zoom Node voor maximaal vijf hostnamen/SAN's bij het gebruik van door de klant aangeleverde certificaten, die hieronder verder worden toegelicht. #### Automatisch certificaatbeheer met Auto PKI Zoom Auto PKI installeert automatisch geldige openbaar vertrouwde CA-certificaten voor het Zoom Node Platform, evenals voor alle modules die erop zijn geïmplementeerd. Certificaatvernieuwing wordt ook automatisch afgehandeld. Dit vereenvoudigt het certificaatbeheer voor alle services en voor Zoom Node zelf. #### Auto PKI-certificaatinschrijving en -vernieuwing begrijpen Het volgende scenario kan u helpen te begrijpen hoe certificaatinschrijving en -vernieuwing werken. Bijvoorbeeld: een beheerder heeft een nieuwe Node-instantie geïmplementeerd. Elke instantie vereist een geldig x509-certificaat. **De privé-sleutel van het certificaat mag deze instantie nooit verlaten**. Het Auto PKI-proces voert de volgende stappen uit: 1. **Sjabloonophaling**: Haalt alle ondersteunde configuratiesjablonen op, inclusief opties voor meerdere CA-providers, van de Auto PKI-service in de Zoom-cloud. 2. **IP-adresverzameling**: Verzamelt alle IP-adressen die door services op de Node worden gebruikt en stuurt ze naar de Auto PKI-service in de Zoom-cloud. 3. **DNS-naamvoorziening**: De Auto PKI Cloud-service retourneert een set DNS-namen in het formaat `..zoomonprem.com`. Deze domeinen zijn geconfigureerd met A/AAAA-records. 4. **Aanvraag voor gereserveerde DNS-naam**: Vraagt een gereserveerde DNS-naam aan in de indeling `rsvd-..zoomonprem.com`. 5. **Genereren van certificaataanvraag**: Genereert een x509-certificaataanvraag, waarbij de DNS-namen uit de derde stap in het SAN-veld worden gebruikt en de gereserveerde naam uit de vierde stap in het Common Name (CN)-veld. 6. **Uitgifte van certificaat**: Verstuurt de Certificaatondertekeningsaanvraag (CSR) naar de Auto PKI-service in de Zoom-cloud. Deze service werkt vervolgens samen met CA-leveranciers om het certificaat uit te geven, dat de SAN-lijst en het CN-veld uit de vorige stap bevat. 7. **Lokale opslag**: Schrijft het nieuw uitgegeven x509-certificaat uit de laatste stap en de bijbehorende privésleutel (eerder gegenereerd) naar lokale opslag, zodat deze Beschikbaar zijn voor services die op de Node-instantie worden uitgevoerd. Auto PKI vereenvoudigt certificaatbeheer op Zoom Node door automatisch vervaldatums te monitoren en nieuwe certificaten aan te vragen, waardoor handmatige verlenging overbodig wordt. #### Breng uw eigen certificaten mee (BYOC) U kunt uw eigen geldige, publiek ondertekende certificaten op Zoom Node installeren met behulp van de lokale webinterface. U kunt dit doen tijdens de eerste installatie of op een later moment. Het proces zal vertrouwd aanvoelen voor degenen die gewend zijn certificaten op webgebaseerde toepassingen te installeren. Als u ervoor kiest uw eigen certificaten te gebruiken, bedenk dan dat het certificaat zich op een server bevindt die met meerdere hostnamen communiceert. Daarom moet het type certificaat dat u kiest ondersteuning bieden voor encryptie voor verkeer dat afkomstig is van meer dan één hostnaam (certificaat-CN). Alle hostnamen die voor Node en eventuele geïmplementeerde services worden gebruikt, moeten publiek oplosbaar zijn via Zoom's Cloud-services. Zoom beveelt twee soorten certificaten aan: * **Wildcard-certificaat** * **Multi-SAN-certificaat** (ook bekend als Multi-Domain-certificaat, SAN-certificaat of UCC-certificaat) {% hint style="danger" %} Een typisch certificaat voor één host zal niet werken met Zoom Node, behalve voor het specifieke scenario waarin één IP-adres en hostnaam worden gedeeld tussen Zoom Node en één module. Zie voor aanvullende context het ZPLS-diagram in de [#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") sectie. {% endhint %} **Wildcard certificaten: Aanbevolen voor eenvoud** Een wildcardcertificaat kan verkeer versleutelen van elke hostnaam in het domein. Bijvoorbeeld: een wildcardcertificaat zoals \*.customer.com kan verkeer versleutelen van `host1.customer.com` en `host2.customer.com` of elke naam binnen `.customer.com`. Wanneer u Zoom Node implementeert en het wildcardcertificaat installeert, zal het automatisch verkeer versleutelen voor alle services die u op de Node implementeert, met de vereiste dat alle geïmplementeerde Services een Fully Qualified Domain Name (FQDN) uit het wildcarddomein gebruiken. Dit minimaliseert de inspanning om services op de Node te implementeren: u hoeft de namen van de services niet te kennen voordat u ze implementeert. U moet echter de servicenamen kennen als u de multi-SAN-certificaatmethode gebruikt. **Multi-SAN-, Multi-Domein-, SAN- of UCC-certificaten** {% hint style="warning" %} U moet de hostnamen en IP-adressen kennen die u voor de Node gaat gebruiken (tot één \[1]) en alle Services die u gaat installeren (tot vier \[4]). **Deze informatie is vereist vóór het aanvragen van een certificaat**. {% endhint %} Een Multi-SAN-certificaat is noodzakelijk voor Zoom Node omdat het verkeer van vijf (5) hostnamen wordt versleuteld. Een eenmalig verzoek voor dit certificaat vereist voorafgaande kennis van alle benodigde informatie, inclusief geplande Node-namen en de namen van alle services die zijn gepland voor implementatie op de Node. Bijvoorbeeld, met een module zoals ZPLS wordt er slechts één ZPLS-module per Node geïmplementeerd, dus is slechts één extra SAN nodig voor de hostnaam van de ZPLS-service. De volgende tabel kan als voorbeeld worden gebruikt: | Hostnaam (SAN) | IP-adres | | -------------------------------------------- | ------------- | | `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` | | (Service 4 - niet gebruikt in dit voorbeeld) | (N/B) | Dit voorbeeld is van een typische configuratie, met één Node waarop ZPLS op hetzelfde IP wordt gehost, plus twee extra services op afzonderlijke IP's. Vervang “company.com” door uw eigen domein en gebruik de IP-adressen van uw netwerk. **Vereisten voor DNS-resolutie** Zoom vereist dat de hostnamen publiek kunnen worden opgelost, zodat wederzijds vertrouwen kan worden स्थापित. Alle Zoom Node-hostnamen en alle servicehostnamen die op de Nodes zijn geïmplementeerd, moeten in de DNS-zone worden opgenomen. Als uw Organisatie aparte interne en externe DNS-services of domeinen gebruikt, moeten de hostnamen van Zoom Node worden gehost in een zone die kan worden opgelost door uw externe DNS-servers (kan worden beperkt tot alleen oplossen voor Zoom IP-bereiken). Uw interne Zoom-gebruikers en de Zoom-cloud moeten communiceren met dezelfde set hostnamen. --- # 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/nl/geavanceerde-diensten-voor-onderneming/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md?ask=&goal= ``` `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.