> 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-ondernemingsservices/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md). # Overwegingen voor de implementatie van Zoom Node Lees meer over hoe verschillende implementatievoorbeelden Zoom Node en Zoom Node-servicemodules ondersteunen Deze sectie bevat verschillende voorbeelden van hoe Zoom Node ondersteuning kan bieden aan verschillende service-modules zoals Zoom Meetings Hybrid en Zoom Phone Local Survivability (ZPLS). Typische implementaties met een toegewezen IP-adres kunnen eruitzien als de volgende verzameling diagrammen. Elke service die op Zoom Node is geïmplementeerd, vereist een uniek IP-adres. Een Zoom Node heeft maximaal vijf (5) IP-adressen toegewezen als de Node een specifiek adres voor beheer heeft gekregen en één voor elke geïmplementeerde service (tot vier) op de Node. Een Zoom Node die één service draait (zoals ZPLS) kan met één IP-adres worden geïmplementeerd als de Node en de service zo worden ingesteld dat ze hetzelfde IP-adres delen. Hieronder worden verschillende implementatieopties getoond. Let op het aantal IP's en certificaten (CN/SAN's) voor de verschillende implementatieopties. ### Optie 1: Zoom Meetings Hybrid geïmplementeerd met toegewezen IP's en hostnamen
De bovenstaande afbeelding vat de IP- en certificaatconfiguratievereisten samen voor het implementeren van **Zoom Meetings Hybrid** in on-premises- of hybride Cloud-omgevingen. De onderstaande tabel werkt 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` | Algemene naam (CN) | Kernorkestratie | | Zoom Connector Proxy | `zcp1.customer.com` | Alternatieve subjectnaam (SAN) | Signalisering en sessiecontrole | | Media Module Router 1 | `mmr1.customer.com` | Alternatieve subjectnaam (SAN) | Media Routering en verwerking | | Media Module Router 2 | `mmr2.customer.com` | Alternatieve subjectnaam (SAN) | Media Routering en verwerking | | Media Module Router 3 | `mmr3.customer.com` | Alternatieve subjectnaam (SAN) | Media Routering en verwerking | {% hint style="info" %} U moet aan elke module een specifiek statisch IP-adres toewijzen. Totaal vereiste IP-adressen: vijf (5) {% endhint %}
De bovenstaande afbeelding schetst de minimale configuratie die nodig is om te implementeren **Lokale veerkracht van Zoom Phone (ZPLS)**. ZPLS zorgt voor continue beschikbaarheid van de telefoondienst bij een internet- of Cloud-storing door overlevingslogica lokaal uit te voeren op een Zoom Node VM. De volgende hostnamen moeten in DNS worden geconfigureerd en worden opgenomen in het TLS-certificaat: * `node1.customer.com` * `zplsl.customer.com` **Functionele hostnaamkoppeling** | Component | Hostnaam | Rol van TLS-certificaat | Functie | | ---------------------- | -------------------- | ------------------------ | ----------------------------------- | | Node-Besturingssysteem | `node1.customer.com` | Algemene naam (CN) | Kernorkestratie | | ZPLS-module | `zplsl.customer.com` | Alternatieve subjectnaam | Zoom Phone lokale overlevingslogica | **TLS-certificaatconfiguratie** | Veld | Waarde | | ------------------------- | -------------------- | | Algemene naam (CN) | `node1.customer.com` | | Alternatieve subjectnamen | `zplsl.customer.com` | Certificaten moeten worden gegenereerd of verkregen (openbare 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. **IP-adresvereisten** | Meetwaarde | Waarde / Beschrijving | | --------------------------- | ---------------------------------------------------------- | | Totaal vereiste IP-adressen | 5 (algemene toewijzing) | | Gebruikt in ZPLS-context | 2 IP's (1 voor Node-Besturingssysteem, 1 voor ZPLS-module) | Hoewel vijf (5) IP's vereist zijn voor algemene implementatie, **worden slechts twee (2) IP-adressen actief gebruikt** in de ZPLS-implementatie: één per module, draaiend op een **toegewijde Node-VM**. {% hint style="warning" %} ZPLS staat alleen éé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 indien gewenst het eerste IP-adres/de eerste 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-adres en een gedeelde hostnaam
Deze configuratie herhaalt de Node-structuur zoals te zien is in het diagram van Zoom Meetings Hybrid in Optie 1. In deze implementatie is echter het **Het Besturingssysteem van de Node deelt zijn IP-adres met de eerst geïmplementeerde module** (meestal de Zoom Connector Proxy, ZCP). Dit resulteert in minder IP-gebruik terwijl aan TLS- en functionele vereisten wordt voldaan. De volgende hostnamen moeten in DNS worden geconfigureerd en worden opgenomen in het TLS-certificaat: * `zcp1.customer.com` * `mmr1.customer.com` * `mmr2.customer.com` * `mmr3.customer.com` **Functionele hostnaamkoppeling** | Component | Hostnaam | Rol van TLS-certificaat | Functie | | -------------------------- | ------------------- | ------------------------------ | ------------------------------- | | ZCP (Zoom Connector Proxy) | `zcp1.customer.com` | Algemene naam (CN) | Signalisering en sessiecontrole | | Media Module Router 1 | `mmr1.customer.com` | Alternatieve subjectnaam (SAN) | Media Routering en verwerking | | Media Module Router 2 | `mmr2.customer.com` | Alternatieve subjectnaam (SAN) | Media Routering en verwerking | | Media Module Router 3 | `mmr3.customer.com` | Alternatieve subjectnaam (SAN) | Media Routering en verwerking | **TLS-certificaatconfiguratie** | Veld | Waarde | | ------------------------- | ------------------------------------------------------------- | | Algemene naam (CN) | `zcp1.customer.com` | | Alternatieve subjectnamen | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` | Certificaten moeten alle SANs bevatten om veilige TLS-communicatie tussen de Zoom Node en de geïnstalleerde Zoom-modules te ondersteunen. **IP-adresvereisten** | Meetwaarde | Waarde / Beschrijving | | ----------------------------- | ---------------------------------------------------------- | | Totaal vereiste IP-adressen | 4 | | IP-deelstrategie | Node Besturingssysteem deelt IP met de eerste module (ZCP) | | Individuele IP's vereist voor | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Wanneer het IP-adres is **gedeeld** tussen het Node Besturingssysteem en de eerst geïmplementeerde module (ZCP), zijn alleen **vier (4) IP-adressen** vereist. Dit ontwerp optimaliseert het IP-gebruik en voldoet tegelijkertijd aan de implementatiestandaarden. {% endhint %}
De bovenstaande afbeelding toont een minimale ZPLS-implementatie waarbij de **Het Besturingssysteem van Node deelt zijn IP-adres met de geïnstalleerde ZPLS-module**. Dit is het **enige scenario** binnen het Zoom Node-framework waarin een **TLS-certificaat voor één host** geldig is. De volgende hostnaam moet in DNS worden geconfigureerd en in het TLS-certificaat worden opgenomen: * `zplsl.customer.com` **Functionele hostnaamkoppeling** | Component | Hostnaam | Rol van TLS-certificaat | Functie | | ----------- | -------------------- | ----------------------- | ----------------------------------- | | ZPLS-module | `zplsl.customer.com` | Algemene naam (CN) | Zoom Phone lokale overlevingslogica | **TLS-certificaatconfiguratie** | Veld | Waarde | | ------------------ | ------------------- | | Algemene naam (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. **IP-adresvereisten** | Meetwaarde | Waarde / Beschrijving | | --------------------------- | ------------------------------------------------------- | | Totaal vereiste IP-adressen | 1 | | IP-deelstrategie | 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 * Er is slechts één (1 )IP-adres vereist voor implementatie vanwege IP-deling van de Besturingssysteem-module * Co-locatie van extra modules op dezelfde VM wordt niet ondersteund {% endhint %} ### Bepaal welke methode voor certificaatbeheer het beste werkt voor uw implementaties Elke Service Module die op Zoom Node wordt geïmplementeerd, vereist een geldig certificaat dat is ondertekend door een publiek vertrouwde certificaatautoriteit (CA) uit de certificaatvertrouwenslijst van Zoom Node. Dit omvat bekende publieke autoriteiten. Zoom Node biedt twee methoden voor certificaatbeheer: * **Auto PKI**: Deze innovatieve oplossing automatiseert veilige certificaatinschrijving en -vernieuwing met publiek vertrouwde certificaatautoriteiten (CA's). Zoom dekt de kosten die verband houden met inschrijving en vernieuwing. * **Breng uw eigen certificaat (BYOC)**: Met deze optie levert u uw eigen certificaten, ondertekend door een grote publiek vertrouwde CA. U beheert de certificaatinschrijving en -vernieuwingen. Er gelden aanvullende overwegingen met betrekking tot het potentieel van Zoom Node voor maximaal vijf hostnames/SAN's bij gebruik van door de klant geleverde certificaten, die hieronder verder worden beschreven. #### Automatisch certificaatbeheer met Auto PKI Zoom Auto PKI installeert automatisch geldige, publiek vertrouwde CA-certificaten voor het Zoom Node Platform, evenals alle modules die daarop zijn geïmplementeerd. Certificaatvernieuwing wordt ook automatisch afgehandeld. Dit vereenvoudigt het certificaatbeheer voor alle services en Zoom Node zelf. #### Begrijpen van certificaatinschrijving en -vernieuwing met Auto PKI Het volgende scenario kan u helpen begrijpen hoe certificaatinschrijving en -vernieuwing werkt. Bijvoorbeeld: een beheerder heeft een nieuwe Node-instantie geïmplementeerd. Voor elke instantie is een geldig x509-certificaat vereist. **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. **Verzameling van IP-adressen**: Verzamelt alle IP-adressen die worden gebruikt door services die op de Node draaien en stuurt ze naar de Auto PKI-service in de Zoom-cloud. 3. **Beschikbaarstelling van DNS-namen**: De Auto PKI Cloud-service geeft een set DNS-namen terug in het formaat `..zoomonprem.com`. Deze domeinen worden geconfigureerd met A/AAAA-records. 4. **Aanvraag voor gereserveerde DNS-naam**: Vraagt een gereserveerde DNS-naam op in de vorm `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. **Certificaatuitgifte**: Stuurt het certificaatondertekeningsverzoek (CSR) naar de Auto PKI-service in de Zoom-cloud. Deze service werkt vervolgens samen met CA-leveranciers om het certificaat uit te geven, inclusief de SAN-lijst en het CN-veld uit de vorige stap. 7. **Lokale opslag**: Schrijft het nieuw uitgegeven x509-certificaat uit de laatste stap en de bijbehorende privésleutel (eerder gegenereerd) naar de lokale opslag, zodat deze beschikbaar zijn voor services die op de Node-instantie draaien. Auto PKI vereenvoudigt het certificaatbeheer op Zoom Node door automatisch vervaldata te bewaken en nieuwe certificaten aan te vragen, waardoor handmatige verlenging niet meer nodig is. #### Breng uw eigen certificaten mee (BYOC) U kunt uw eigen geldige, publiek ondertekende certificaten op Zoom Node installeren via de lokale webinterface. U kunt dit doen tijdens de eerste installatie of op een later moment. Het proces zal vertrouwd zijn voor degenen die gewend zijn certificaten op webgebaseerde toepassingen te installeren. Als u ervoor kiest uw eigen certificaten te gebruiken, vergeet dan niet dat het certificaat zich op een server bevindt die communiceert met meerdere hostnamen. Kies een certificaattype dat ondersteuning biedt voor encryptie van verkeer dat afkomstig is van meer dan één hostnaam (certificaat-CN). Alle hostnamen die voor Node en alle geïmplementeerde services worden gebruikt, moeten publiek kunnen worden opgelost door de Cloudservices van Zoom. Zoom raadt 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 werkt niet met Zoom Node, behalve in het specifieke scenario waarin één IP-adres en hostnaam worden gedeeld tussen Zoom Node en één module. Voor extra context, zie 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 wildcard-certificaat kan encryptie bieden voor verkeer van elke hostnaam in het domein. Bijvoorbeeld: een wildcard-certificaat zoals \*.customer.com kan encryptie bieden voor `host1.customer.com` en `host2.customer.com` of elke naam binnen `.customer.com`. Wanneer u Zoom Node implementeert en het wildcard-certificaat 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-Domain-, SAN- of UCC-certificaattypen** {% hint style="warning" %} U moet de hostnamen en IP-adressen kennen die u voor de Node zult gebruiken (tot één \[1]) en eventuele Services die u zult installeren (tot vier \[4]). **Deze informatie is vereist voordat u een certificaat aanvraagt**. {% endhint %} Een Multi-SAN-certificaat is noodzakelijk voor Zoom Node omdat het verkeer van vijf (5) hostnamen versleutelt. Een eenmalige aanvraag voor dit certificaat vereist vooraf kennis van alle noodzakelijke informatie, inclusief geplande Node-namen en de namen van alle services die op de Node zullen worden uitgerold. Bijvoorbeeld: bij een module zoals ZPLS wordt per Node slechts één ZPLS-module uitgerold, 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.v.t.) | Dit voorbeeld is een typische configuratie, met één Node die ZPLS host op hetzelfde IP 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 publiekelijk resolvable zijn, zodat wederzijds vertrouwen kan worden opgebouwd. Alle Zoom Node-hostnamen en alle servicenames die op de Nodes zijn geïmplementeerd, moeten in de DNS-zone worden opgenomen. Als uw Organisatie afzonderlijke interne en externe DNS-diensten of -domeinen gebruikt, moeten de hostnamen van Zoom Node worden gehost in een zone die kan worden omgezet 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-ondernemingsservices/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.