# Zoom Node Dağıtım Hususları Bu bölüm, Zoom Node’un Zoom Meetings Hybrid ve Zoom Phone Local Survivability (ZPLS) gibi çeşitli Hizmet Modüllerini nasıl destekleyebileceğine dair birkaç örnek içerir. Özel bir IP Adresi ile tipik dağıtımlar aşağıdaki diyagram koleksiyonu gibi görünebilir. Zoom Node üzerinde dağıtılan her hizmet benzersiz bir IP Adresi gerektirir. Bir Zoom Node’a, Node yönetim için belirli bir adres ve Node üzerinde dağıtılan her hizmet için (en fazla dört) bir adres atanmışsa en fazla beş (5) IP Adresi atanır. Tek bir hizmeti (ZPLS gibi) çalıştıran bir Zoom Node, Node ve hizmet aynı IP Adresini paylaşacak şekilde atanmışsa tek bir IP Adresi ile dağıtılabilir. Aşağıda birkaç dağıtım seçeneği gösterilmiştir. Çeşitli dağıtım seçenekleri için IP sayısına ve sertifikalara (CN/SAN’ler) dikkat edin. ### Seçenek 1: Özel IP’ler ve ana bilgisayar adlarıyla dağıtılan Zoom Meetings Hybrid
Yukarıdaki görsel, dağıtım için IP ve sertifika yapılandırma gereksinimlerini özetlemektedir **Zoom Meetings Hybrid** şirket içi veya hibrit bulut ortamlarında. Aşağıdaki tablo, örnek Node’u ayrıntılı olarak gösterir ve Aktif proxy ile MMR Hizmet Modüllerini içerir: | Bileşen | Ana bilgisayar adı | TLS Sertifika Rolü | İşlev | | --------------------------- | -------------------- | ------------------------- | ----------------------------- | | Node işletim sistemi | `node1.customer.com` | Ortak Ad (CN) | Çekirdek orkestrasyon | | Zoom Bağlayıcı Proxy | `zcp1.customer.com` | Konu Alternatif Adı (SAN) | Sinyalleme ve oturum kontrolü | | Medya Modülü Yönlendirici 1 | `mmr1.customer.com` | Konu Alternatif Adı (SAN) | Medya Yönlendirme ve işleme | | Medya Modülü Yönlendirici 2 | `mmr2.customer.com` | Konu Alternatif Adı (SAN) | Medya Yönlendirme ve işleme | | Medya Modülü Yönlendirici 3 | `mmr3.customer.com` | Konu Alternatif Adı (SAN) | Medya Yönlendirme ve işleme | {% hint style="info" %} Her modüle özel bir statik IP Adresi Atamanız gerekir. Gerekli toplam IP Adresi sayısı: beş (5) {% endhint %}
Yukarıdaki görsel, dağıtım için gereken minimum yapılandırmayı ana hatlarıyla belirtir **Zoom Phone Local Survivability (ZPLS)**. ZPLS, internet veya bulut kesintisi durumunda, bir Zoom Node VM üzerinde yerel olarak hayatta kalma mantığını çalıştırarak telefon hizmetinin kullanılabilirliğinin sürmesini sağlar. Aşağıdaki ana bilgisayar adları DNS’te yapılandırılmalı ve TLS sertifikasına dahil edilmelidir: * `node1.customer.com` * `zplsl.customer.com` **Ana Bilgisayar Adı İşlevsel Eşlemesi** | Bileşen | Ana bilgisayar adı | TLS Sertifika Rolü | İşlev | | -------------------- | -------------------- | ------------------- | -------------------------------------- | | Node işletim sistemi | `node1.customer.com` | Ortak Ad (CN) | Çekirdek orkestrasyon | | ZPLS Modülü | `zplsl.customer.com` | Konu Alternatif Adı | Zoom Phone Local Survivability mantığı | **TLS Sertifika Yapılandırması** | Alan | Değer | | ---------------------- | -------------------- | | Ortak Ad (CN) | `node1.customer.com` | | Konu Alternatif Adları | `zplsl.customer.com` | Sertifikalar, yukarıda listelenen hem CN’yi hem de SAN’leri içerecek şekilde oluşturulmalı veya temin edilmelidir (genel ya da özel CA). Bu, güvenli modüller arası iletişim için uygun TLS doğrulamasını sağlar. **IP Adresi Gereksinimleri** | Metrik | Değer / Açıklama | | ------------------------------- | ------------------------------------------------------ | | Gerekli Toplam IP Adresi Sayısı | 5 (genel tahsis) | | ZPLS Bağlamında Kullanılan | 2 IP (1 Node işletim sistemi için, 1 ZPLS modülü için) | Genel dağıtım için beş (5) IP gerektiği halde, **yalnızca iki (2) IP Adresi aktif olarak kullanılır** ZPLS dağıtımında: modül başına bir tane, bir üzerinde çalışıyor **özel Node VM**. {% hint style="warning" %} ZPLS, Node VM başına yalnızca bir modüle izin verir. ZPLS’yi aynı VM üzerinde diğer Zoom modülleriyle birlikte konumlandıramazsınız. {% endhint %} Bu diyagramlar nasıl karşılaştırılır? İlk görüntü bir Zoom Meetings Hybrid dağıtımına örnek gösteriyor. İkinci görüntü, bir Zoom Phone Local Survivability dağıtımına örnek gösteriyor. İstenirse, gereken IP adresleri, oturum adları ve Subject Alternative Names (SANs) sayısını azaltmak için ilk IP/oturum adı işletim sistemi ile ilk modül arasında paylaşılabilir. ### Seçenek 2: Paylaşılan IP ve paylaşılan oturum adı ile dağıtılmış Zoom Meetings Hybrid
Bu yapılandırma, Seçenek 1 Zoom Meetings Hybrid diyagramında görülen Node yapısını tekrar eder. Ancak bu dağıtımda, **Node işletim sistemi IP Adresi’ni ilk dağıtılan modülle paylaşır** (genellikle Zoom Bağlayıcı Proxy, ZCP). Bu, TLS ve işlevsel gereksinimleri korurken IP kullanımını azaltır. Aşağıdaki ana bilgisayar adları DNS’te yapılandırılmalı ve TLS sertifikasına dahil edilmelidir: * `zcp1.customer.com` * `mmr1.customer.com` * `mmr2.customer.com` * `mmr3.customer.com` **Ana Bilgisayar Adı İşlevsel Eşlemesi** | Bileşen | Ana bilgisayar adı | TLS Sertifika Rolü | İşlev | | --------------------------- | ------------------- | ------------------------- | ----------------------------- | | ZCP (Zoom Bağlayıcı Proxy) | `zcp1.customer.com` | Ortak Ad (CN) | Sinyalleme ve oturum kontrolü | | Medya Modülü Yönlendirici 1 | `mmr1.customer.com` | Konu Alternatif Adı (SAN) | Medya Yönlendirme ve işleme | | Medya Modülü Yönlendirici 2 | `mmr2.customer.com` | Konu Alternatif Adı (SAN) | Medya Yönlendirme ve işleme | | Medya Modülü Yönlendirici 3 | `mmr3.customer.com` | Konu Alternatif Adı (SAN) | Medya Yönlendirme ve işleme | **TLS Sertifika Yapılandırması** | Alan | Değer | | ---------------------- | ------------------------------------------------------------- | | Ortak Ad (CN) | `zcp1.customer.com` | | Konu Alternatif Adları | `mmr1.customer.com`, `mmr2.customer.com`, `mmr3.customer.com` | Sertifikalar, Zoom Node ile yüklü Zoom modülleri arasında güvenli TLS iletişimini desteklemek için tüm SANs’leri içermelidir. **IP Adresi Gereksinimleri** | Metrik | Değer / Açıklama | | ------------------------------- | ----------------------------------------------------- | | Gerekli Toplam IP Adresi Sayısı | 4 | | IP Paylaşım Stratejisi | Node işletim sistemi IP’yi ilk modülle paylaşır (ZCP) | | Gerekli Bireysel IP’ler | ZCP/MMR1, MMR2, MMR3 | {% hint style="info" %} IP Adresi **paylaşıldığında** Node işletim sistemi ile ilk dağıtılan modül (ZCP) arasında, yalnızca **dört (4) IP Adresi** gerekir. Bu tasarım, dağıtım standartlarına yine de uyarken IP kullanımını optimize eder. {% endhint %}
Yukarıdaki görüntü, **Node işletim sisteminin IP Adresi’ni yüklü ZPLS modülüyle paylaştığı minimum bir ZPLS dağıtımını gösterir**. Bu, **tek senaryo** Zoom Node çerçevesinde bir **tek oturum sahibi TLS sertifikasının** geçerli olduğu. Aşağıdaki oturum adı DNS’te yapılandırılmalı ve TLS sertifikasına dahil edilmelidir: * `zplsl.customer.com` **Ana Bilgisayar Adı İşlevsel Eşlemesi** | Bileşen | Ana bilgisayar adı | TLS Sertifika Rolü | İşlev | | ----------- | -------------------- | ------------------ | -------------------------------------- | | ZPLS Modülü | `zplsl.customer.com` | Ortak Ad (CN) | Zoom Phone Local Survivability mantığı | **TLS Sertifika Yapılandırması** | Alan | Değer | | ------------- | ------------------- | | Ortak Ad (CN) | `zcp1.customer.com` | | SANs | (gerekli değil) | Bu yapılandırmada, işletim sistemi ve ZPLS modülü aynı oturum adını ve IP Adresi’ni paylaştığından tek oturum sahibi sertifika yeterlidir. **IP Adresi Gereksinimleri** | Metrik | Değer / Açıklama | | ------------------------------- | --------------------------------------------------------------- | | Gerekli Toplam IP Adresi Sayısı | 1 | | IP Paylaşım Stratejisi | Node işletim sistemi ve ZPLS tek bir IP Adresi paylaşır | | Dağıtım Kısıtı | Node VM başına yalnızca bir modüle izin verilir (yalnızca ZPLS) | {% hint style="warning" %} ZPLS, Zoom Node mimarisinde aşağıdaki durumların geçerli olduğu tek desteklenen senaryodur: * Tek oturum sahibi bir sertifika (yalnızca CN) kabul edilebilir * İşletim sistemi-modül IP paylaşımı nedeniyle dağıtım için yalnızca bir (1) IP Adresi gerekir * Aynı VM üzerinde ek modüllerin birlikte konumlandırılması desteklenmez {% endhint %} ### Dağıtımlarınız için hangi sertifika yönetim yönteminin en iyi çalıştığına karar verin Zoom Node üzerinde dağıtılan her Servis Modülü, Zoom Node’un sertifika güven listesinde yer alan, kamuya açık olarak güvenilen bir Sertifika Yetkilisi (CA) tarafından imzalanmış geçerli bir sertifika gerektirir. Buna, yaygın olarak bilinen kamu otoriteleri dahildir. Zoom Node iki sertifika yönetim yöntemi sunar: * **Auto PKI**: Bu yenilikçi çözüm, kamuya açık olarak güvenilen Sertifika Yetkilileri (CA’ler) ile güvenli sertifika kaydını ve yenilemeyi otomatikleştirir. Zoom, kayıt ve yenileme ile ilişkili maliyetleri karşılar. * **Kendi Sertifikanızı Getirin (BYOC)**: Bu seçenekte, kendi sertifikalarınızı, büyük kamuya açık güvenilen herhangi bir CA tarafından imzalanmış şekilde sağlarsınız. Sertifika kaydını ve yenilemelerini siz yönetirsiniz. Müşteri tarafından sağlanan sertifikalar kullanıldığında Zoom Node’un beş adede kadar oturum adı/SAN desteği potansiyeliyle ilgili ek hususlar vardır; bunlar aşağıda daha ayrıntılı olarak açıklanmıştır. #### Auto PKI ile Otomatik Sertifika Yönetimi Zoom Auto PKI, Zoom Node platformu için olduğu kadar üzerinde dağıtılan tüm modüller için de geçerli, kamuya açık olarak güvenilen CA sertifikalarını otomatik olarak yükler. Sertifika yenilemesi de otomatik olarak yönetilir. Bu, tüm hizmetler ve Zoom Node’un kendisi için sertifika yönetimini basitleştirir. #### Auto PKI Sertifika Kaydı ve Yenilemesini Anlama Aşağıdaki senaryo, sertifika kaydı ve yenilemenin nasıl çalıştığını anlamanıza yardımcı olabilir. Örneğin: Bir yönetici yeni bir Node örneği dağıtmıştır. Her örnek geçerli bir x509 sertifikası gerektirir. **Bu sertifikanın özel anahtarı bu örneği asla terk etmemelidir**. Auto PKI süreci aşağıdaki adımları gerçekleştirir: 1. **Şablon Alma**: Çoklu CA sağlayıcıları için seçenekler de dahil olmak üzere desteklenen tüm yapılandırma şablonlarını Auto PKI hizmetinden Zoom bulut içinde çeker. 2. **IP Adresi Toplama**: Node üzerinde çalışan hizmetler tarafından kullanılan tüm IP Adreslerini toplar ve bunları Auto PKI hizmetine Zoom bulut içinde gönderir. 3. **DNS Adı Sağlama**: Auto PKI bulut hizmeti, aşağıdaki biçimde bir dizi DNS adı döndürür `<örnek_tanımlayıcı>..zoomonprem.com`. Bu alan adları A/AAAA kayıtları ile yapılandırılır. 4. **Ayrılmış DNS Adı İsteği**: Şu biçimde ayrılmış bir DNS adı ister `rsvd-..zoomonprem.com`. 5. **sertifika İsteği Oluşturma**: SAN alanında üçüncü adımdaki DNS adlarını ve Ortak Ad (CN) alanında dördüncü adımdaki ayrılmış adı kullanarak bir x509 sertifika isteği oluşturur. 6. **sertifika Verilmesi**: Sertifika İmzalama İsteğini (CSR) Zoom bulut içindeki Auto PKI hizmetine gönderir. Bu hizmet daha sonra sertifikayı vermek için CA sağlayıcılarıyla birlikte çalışır; bu sertifika, önceki adımdaki SAN listesini ve CN alanını içerir. 7. **Yerel Depolama**: Son adımdan yeni verilmiş x509 sertifikayı ve buna karşılık gelen özel anahtarını (daha önce oluşturulmuş) yerel depolamaya yazar ve bunları Node örneğinde çalışan hizmetler için kullanılabilir hale getirir. Auto PKI, sona erme tarihlerini otomatik olarak izleyip yeni sertifikalar isteyerek Zoom Node üzerindeki sertifika yönetimini basitleştirir ve manuel yenileme gereksinimini ortadan kaldırır. #### Kendi Sertifikalarınızı Getirin (BYOC) Yerel web arayüzünü kullanarak Zoom Node üzerine kendi geçerli, herkese açık olarak imzalanmış sertifikalarınızı yükleyebilirsiniz. Bunu ilk kurulum sırasında veya daha sonra yapabilirsiniz. Bu süreç, web tabanlı uygulamalara sertifika yüklemeye alışkın olanlara tanıdık gelecektir. Kendi sertifikalarınızı kullanmayı seçerseniz, sertifikanın birden fazla oturum sahibi adıyla iletişim kuran bir sunucuda olacağını unutmayın. Bu nedenle, seçtiğiniz sertifika türü, birden fazla oturum sahibi adından (sertifika CN) kaynaklanan trafik için şifrelemeyi desteklemelidir. Node ve dağıtılan herhangi bir hizmet için kullanılan tüm oturum sahibi adları, Zoom'un bulut hizmetleri tarafından herkese açık olarak çözümlenebilir olmalıdır. Zoom iki tür sertifika önerir: * **Wildcard Sertifika** * **Multi-SAN Sertifika** (Multi-Domain Sertifika, SAN Sertifika veya UCC Sertifika olarak da bilinir) {% hint style="danger" %} Standart tek oturum sahibi sertifikası, Zoom Node ile tek bir modül arasında tek bir IP Adresi ve oturum sahibi adının paylaşıldığı belirli senaryo hariç, Zoom Node ile çalışmaz. Ek bağlam için, içindeki ZPLS diyagramına bakın [#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") bölümü. {% endhint %} **Wildcard Sertifikaları: Basitlik için önerilir** Wildcard sertifika, alan adındaki herhangi bir oturum sahibi adından gelen trafiği şifreleyebilir. Örneğin: \*.customer.com gibi bir wildcard sertifika, şuradan gelen trafiği şifreleyebilir `host1.customer.com` hem de `host2.customer.com` veya içindeki herhangi bir ad `.customer.com`. Zoom Node'u dağıttığınızda ve wildcard sertifikayı yüklediğinizde, Node üzerinde dağıttığınız herhangi bir hizmet için trafiği otomatik olarak şifreler; bunun koşulu, dağıtılan tüm Hizmetlerin wildcard alan adından tam nitelikli bir alan adı (FQDN) kullanmasıdır. Bu, Node üzerinde hizmet dağıtma çabasını en aza indirir: bunları dağıtmadan önce hizmetlerin adlarını bilmeniz gerekmez. Ancak, çoklu SAN sertifika yöntemini kullanıyorsanız hizmet adlarını bilmeniz gerekir. **Çoklu-SAN, Çoklu Alan Adı, SAN veya UCC sertifikalar** {% hint style="warning" %} Node için kullanacağınız ana bilgisayar adlarını ve IP adreslerini (en fazla bir \[1]) ve kuracağınız herhangi bir Hizmeti (en fazla dört \[4]) bilmelisiniz. **Bu bilgiler, bir sertifikaya kaydolmadan önce gereklidir**. {% endhint %} Bir Çoklu-SAN sertifikası, beş (5) ana bilgisayar adından gelen trafiği şifrelediği için Zoom Node için gereklidir. Bu sertifika için tek seferlik bir talep, planlanan Node adları ve Node üzerinde dağıtıma alınacak tüm hizmetlerin adları dahil olmak üzere gerekli tüm bilgilerin önceden bilinmesini gerektirir. Örneğin, ZPLS gibi bir modülde her Node için yalnızca bir ZPLS modülü dağıtılır, bu nedenle ZPLS hizmet ana bilgisayar adı için yalnızca bir ek SAN gerekir. Aşağıdaki tablo bir örnek olarak kullanılabilir: | Ana makine adı (SAN) | IP Adresi | | ------------------------------------- | ------------- | | `zoom-node01.company.com` | `10.1.50.100` | | `zpls.company.com` | `10.1.50.100` | | `zoom-recording.company.com` | `10.1.50.101` | | `zoom-web semineri.company.com` | `10.1.50.102` | | (Hizmet 4 - bu örnekte kullanılmıyor) | (Yok) | Bu örnek, aynı IP üzerinde ZPLS'yi barındıran bir Düğüm ve ayrı IP'lerde iki ek hizmet içeren tipik bir yapılandırmadır. “company.com” ifadesini kendi alan adınızla değiştirin ve ağınızın IP adreslerini kullanın. **DNS Çözümleme Gereksinimleri** Zoom, iki yönlü güvenin kurulabilmesi için ana bilgisayar adlarının genel olarak çözümlenebilir olmasını gerektirir. Tüm Zoom Node ana bilgisayar adları ve Node'larda dağıtılan tüm hizmet ana bilgisayar adları DNS Bölgesi'ne dahil edilmelidir. Eğer Organizasyonunuz ayrı iç ve dış DNS hizmetleri veya etki alanları kullanıyorsa, Zoom Node ana bilgisayar adlarının dış DNS sunucularınız tarafından çözümlenebilen bir bölgede barındırılması gerekir (yalnızca Zoom IP aralıkları için çözümleyecek şekilde kısıtlanabilir). İç Zoom kullanıcılarınız ve Zoom bulut aynı ana bilgisayar adları kümesini kullanarak iletişim kurmalıdır.