# Overwegingen voor Zoom Node-implementatie 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 toegewezen 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 maximaal 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 wordt uitgevoerd (zoals ZPLS) kan met één IP-adres worden geïmplementeerd als de Node en de service zijn toegewezen om hetzelfde IP-adres te 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 vereisten voor IP- en certificaatconfiguratie samen voor het implementeren van **Zoom Meetings Hybrid** in on-premises of hybrid Cloud-omgevingen. De onderstaande tabel splitst de voorbeeld-Node uit en bevat de actieve proxy- en MMR Service Modules: | Component | Hostnaam | TLS-certificaat Rol | 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 toewijzen. Totaal aantal vereiste IP-adressen: vijf (5) {% endhint %}
De bovenstaande afbeelding schetst de minimale configuratie die nodig is om **Zoom Phone Local Survivability (ZPLS)**. ZPLS maakt voortgezette beschikbaarheid van telefoondiensten mogelijk in het geval van internet- of Cloud-verstoring door overlevingslogica 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` **Hostnaam functionele mapping** | Component | Hostnaam | TLS-certificaat Rol | Functie | | ---------------------- | -------------------- | ------------------------ | ------------------------------------------ | | Node-Besturingssysteem | `node1.customer.com` | Common Name (CN) | Kernorkestratie | | ZPLS-module | `zplsl.customer.com` | Subject Alternative Name | Logica voor Zoom Phone Local Survivability | **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) zodat zowel de CN als de hierboven vermelde SAN's zijn opgenomen. Dit maakt correcte TLS-validatie mogelijk voor veilige communicatie tussen modules. **Vereisten voor IP-adres** | Metriek | Waarde / beschrijving | | --------------------------------- | ---------------------------------------------------------- | | Totaal vereist aantal 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, **slechts twee (2) IP-adressen worden actief gebruikt** in de ZPLS-implementatie: één per module, draaiend op een **specifieke Node-VM**. {% hint style="warning" %} ZPLS staat slechts één module per Node-VM toe. U kunt ZPLS niet samen met andere Zoom-modules op dezelfde VM 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 het eerste IP/hostnaam delen tussen het Besturingssysteem en de eerste module, indien gewenst, om het aantal vereiste IP-adressen, hostnamen en Subject Alternative Names (SAN's) te verminderen. ### Optie 2: Zoom Meetings Hybrid geïmplementeerd met een gedeeld IP en een gedeelde hostnaam
Deze configuratie herhaalt de Node-structuur zoals te zien is in het Zoom Meetings Hybrid-diagram van Optie 1. In deze implementatie is echter 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` **Hostnaam functionele mapping** | Component | Hostnaam | TLS-certificaat Rol | 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 veilige TLS-communicatie tussen de Zoom Node en de geïnstalleerde Zoom-modules te ondersteunen. **Vereisten voor IP-adres** | Metriek | Waarde / beschrijving | | -------------------------------------- | ------------------------------------------------------------------------------- | | Totaal vereist aantal IP-adressen | 4 | | IP-deelstrategie | Het Besturingssysteem van de node deelt een IP-adres met de eerste module (ZCP) | | Afzonderlijke IP-adressen vereist voor | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} Wanneer het IP-adres is **gedeeld** tussen het Besturingssysteem van de node en de eerst geïmplementeerde module (ZCP), slechts **vier (4) IP-adressen** zijn vereist. Dit ontwerp optimaliseert het IP-gebruik terwijl het nog steeds voldoet aan de implementatiestandaarden. {% endhint %}
De bovenstaande afbeelding toont een minimale ZPLS-implementatie waarbij de **Node Besturingssysteem deelt zijn IP-adres met de geïnstalleerde ZPLS-module**. Dit is het **enige scenario** in het Zoom Node-framework waarbij een **TLS-certificaat voor één host** geldig is. De volgende hostnaam moet in DNS worden geconfigureerd en worden opgenomen in het TLS-certificaat: * `zplsl.customer.com` **Hostnaam functionele mapping** | Component | Hostnaam | TLS-certificaat Rol | Functie | | ----------- | -------------------- | ------------------- | ------------------------------------------ | | ZPLS-module | `zplsl.customer.com` | Common Name (CN) | Logica voor Zoom Phone Local Survivability | **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-adres** | Metriek | Waarde / beschrijving | | --------------------------------- | --------------------------------------------------------------- | | Totaal vereist aantal IP-adressen | 1 | | IP-deelstrategie | Het Besturingssysteem van Node en ZPLS delen een enkel IP-adres | | Implementatiebeperking | Slechts één module toegestaan per Node-VM (alleen ZPLS) | {% hint style="warning" %} ZPLS is het enige ondersteunde scenario in de architectuur van Zoom Node waarin: * Een certificaat voor één host (alleen CN) acceptabel is * Slechts één (1) IP-adres is vereist voor implementatie vanwege het delen van het IP-adres tussen 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 servicemodule die op Zoom Node is geïmplementeerd, vereist een geldig certificaat dat is ondertekend door een publiek vertrouwde certificaatautoriteit (CA) uit de certificaat-vertrouwenslijst van Zoom Node. Dit omvat algemeen bekende publieke autoriteiten. Zoom Node biedt twee methoden voor certificaatbeheer: * **Automatische PKI**: Deze innovatieve oplossing automatiseert veilige certificaatregistratie en -vernieuwing met publiek vertrouwde certificeringsinstanties (CA's). Zoom dekt de kosten die verband houden met registratie en vernieuwing. * **Breng uw eigen certificaat (BYOC)**: Met deze optie levert u uw eigen certificaten, ondertekend door een van de grote, publiek vertrouwde CA's. U beheert de certificaatinschrijving en verlengingen. Aanvullende aandachtspunten zijn van toepassing met betrekking tot het potentieel van Zoom Node voor maximaal vijf hostnamen/SAN's bij gebruik van door de klant aangeleverde certificaten, die hieronder verder worden toegelicht. #### Automatisch certificaatbeheer met Auto PKI Zoom Auto PKI installeert automatisch geldige, publiek vertrouwde CA-certificaten voor het Zoom Node Platform, evenals voor alle modules die daarop worden geïmplementeerd. Vernieuwing van certificaten wordt ook automatisch afgehandeld. Dit vereenvoudigt het certificaatbeheer voor alle services en voor Zoom Node zelf. #### Inzicht in automatische PKI-certificaatinschrijving en -vernieuwing Het volgende scenario kan u helpen begrijpen hoe certificaatregistratie en -vernieuwing werkt. 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. **Sjabloon ophalen**: Haalt alle ondersteunde configuratiesjablonen op, inclusief opties voor meerdere CA-providers, van de Auto PKI-service in de Zoom-cloud. 2. **IP-adressen verzamelen**: Verzamelt alle IP-adressen die worden gebruikt door services die op de Node worden uitgevoerd en verzendt ze naar de Auto PKI-service in de Zoom-cloud. 3. **DNS-namen verstrekken**: De Auto PKI-Cloudservice retourneert een reeks DNS-namen in de indeling `..zoomonprem.com`. Deze domeinen zijn geconfigureerd met A/AAAA-records. 4. **Aanvraag voor gereserveerde DNS-naam**: Vraagt een gereserveerde DNS-naam aan in het formaat `rsvd-..zoomonprem.com`. 5. **Generatie van certificaataanvraag**: Genereert een x509-certificaatverzoek, met de DNS-namen uit de derde stap in het SAN-veld en de gereserveerde naam uit de vierde stap in het Common Name (CN)-veld. 6. **Certificaatuitgifte**: Stuurt de Certificate Signing Request (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 vorige stap en de bijbehorende privésleutel (eerder gegenereerd) naar lokale opslag, waardoor deze beschikbaar zijn voor services die draaien op de Node-instantie. Auto PKI vereenvoudigt het beheer van certificaten op Zoom Node door automatisch vervaldata te controleren en nieuwe certificaten aan te vragen, waardoor handmatige vernieuwing niet meer nodig is. #### Breng uw eigen certificaten mee (BYOC) U kunt uw eigen geldige, openbaar 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 wie gewend is certificaten te installeren op webgebaseerde applicaties. Als u ervoor kiest uw eigen certificaten te gebruiken, onthoud dan dat het certificaat zich op een server bevindt die met meerdere hostnamen communiceert. Daarom moet het type certificaat dat u Kies ondersteuning bieden voor encryptie van verkeer dat afkomstig is van meer dan één hostnaam (certificaat-CN). Alle hostnamen die worden gebruikt voor Node en eventuele geïmplementeerde services moeten openbaar resolveerbaar zijn door de Cloud-services van Zoom. Zoom beveelt twee soorten certificaten aan: * **Wildcard-certificaat** * **Multi-SAN-certificaat** (ook bekend als Multi-Domein-certificaat, SAN-certificaat of UCC-certificaat) {% hint style="danger" %} Een typisch single-host-certificaat werkt niet met Zoom Node, behalve in het specifieke scenario waarin één enkel IP-adres en één hostnaam worden gedeeld tussen Zoom Node en één enkele 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 certificaat: Aanbevolen voor eenvoud** Een wildcardcertificaat kan verkeer van elke hostnaam in het domein versleutelen. 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 wel 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 (maximaal één \[1]) en alle Services die u gaat installeren (maximaal vier \[4]). **Deze informatie is vereist voordat een certificaat wordt geregistreerd**. {% endhint %} Een Multi-SAN certificaat is nodig voor Zoom Node omdat het verkeer van vijf (5) hostnamen versleutelt. Voor een eenmalige aanvraag voor dit certificaat is vooraf kennis nodig van alle noodzakelijke 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 slechts één ZPLS-module per Node geïmplementeerd, dus is slechts één extra SAN nodig voor de servicehostnaam van ZPLS. 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 დამატыя? **DNS-resolutievereisten** Zoom vereist dat de hostnamen publiek kunnen worden opgelost, zodat wederzijds vertrouwen kan worden vastgesteld. Alle Zoom Node-hostnamen en alle servicehostnamen die op de Nodes zijn geïmplementeerd, moeten worden opgenomen in de DNS-zone. Als uw Organisatie aparte interne en externe DNS-services of domeinen gebruikt, moeten de Zoom Node-hostnamen worden gehost in een zone die kan worden opgelost door uw externe DNS-servers (kan worden beperkt tot alleen resolutie voor Zoom-IP-bereiken). Uw interne Zoom-gebruikers en de Zoom-cloud moeten communiceren met dezelfde set hostnamen. --- # 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/nl/geavanceerde-onderneming-services/zoom-node/zoom-node-deployment-field-guide/zoom-node-deployment-considerations.md?ask= ``` 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.