ISC Konsorsiyumu DHCP sunucusu sürümü klasik ISC DHCP'nin yerini alıyor. Proje kaynakları lisans altında , daha önce ISC DHCP için kullanılan ISC Lisansı yerine.
Kea DHCP sunucusu BIND 10'u temel alır ve işlevselliği farklı işlemci süreçlerine bölmeyi ima eden modüler bir mimari kullanmak. Ürün, ISC DHCP'nin yerini alabilecek, DHCPv4 ve DHCPv6 protokollerini destekleyen tam özellikli bir sunucu uygulaması içerir. Kea, DNS bölgelerini (Dinamik DNS) dinamik olarak güncellemek için yerleşik araçlara sahiptir; sunucu keşfi, adres atama, güncelleme ve yeniden bağlanma, bilgi isteklerine hizmet verme, ana bilgisayarlar için adres ayırma ve PXE önyükleme mekanizmalarını destekler. DHCPv6 uygulaması ayrıca önekleri devretme olanağı da sağlar. Harici uygulamalarla etkileşim kurmak için özel bir API sağlanmıştır. Sunucuyu yeniden başlatmadan yapılandırmayı anında güncellemek mümkündür.
Tahsis edilen adresler ve istemci parametreleri hakkındaki bilgiler farklı depolama türlerinde saklanabilir - şu anda CSV dosyaları, MySQL DBMS, Apache Cassandra ve PostgreSQL'de depolama için arka uçlar sağlanmaktadır. Ana bilgisayar rezervasyon parametreleri, JSON formatındaki bir yapılandırma dosyasında veya MySQL ve PostgreSQL'de bir tablo olarak belirtilebilir. DHCP sunucu performansını ölçmek için perfdhcp aracını ve istatistik toplamak için bileşenleri içerir. Kea iyi bir performans sergiliyor; örneğin, MySQL arka ucunu kullanırken sunucu saniyede 1000 adres ataması gerçekleştirebilir (saniyede yaklaşık 4000 paket) ve memfile arka ucunu kullanırken performans saniyede 7500 atamaya ulaşır.
Anahtar Kea 1.6'da:
- Birkaç DHCPv4 ve DHCPv6 sunucusunun ayarlarını merkezi olarak yönetmenize olanak tanıyan bir yapılandırma arka ucu (CB, Yapılandırma Arka Uç) uygulanmıştır. Arka uç, genel ayarlar, paylaşılan ağlar, alt ağlar, seçenekler, havuzlar ve seçenek tanımları dahil olmak üzere çoğu Kea ayarını depolamak için kullanılabilir. Tüm bu ayarları yerel bir yapılandırma dosyasında saklamak yerine artık harici bir veritabanına yerleştirilebilirler. Bu durumda, CB aracılığıyla ayarların tamamını değil, bazılarını, harici veritabanından ve yerel yapılandırma dosyalarından parametreleri üst üste bindirerek belirlemek mümkündür (örneğin, ağ arayüzü ayarları yerel dosyalarda bırakılabilir).
Yapılandırmayı depolamaya yönelik DBMS'lerden yalnızca MySQL şu anda desteklenmektedir (adres atama veritabanlarını (kiralamalar) depolamak için MySQL, PostgreSQL ve Cassandra kullanılabilir ve ana bilgisayarları ayırmak için MySQL ve PostgreSQL kullanılabilir). Veritabanındaki konfigürasyon, DBMS'ye doğrudan erişim yoluyla veya konfigürasyon yönetimi için parametrelerin, bağlantıların, DHCP seçeneklerinin ve alt ağların eklenmesi ve silinmesi gibi standart bir komut seti sağlayan özel olarak hazırlanmış katman kütüphaneleri aracılığıyla değiştirilebilir;
- İstenmeyen trafiği, örneğin belirli DHCP mesajı türlerini bırakmak için kullanılabilecek yeni bir "DROP" işleyici sınıfı eklendi (DROP sınıfıyla ilişkili tüm paketler hemen bırakılır);
- Yeni parametreler maksimum kiralama süresi ve minimum kiralama süresi eklendi; bu, istemciye bağlanan adresin (kiralama) ömrünü sabit kodlanmış bir değer biçiminde değil, bir kabul edilebilir aralık;
- DHCP standartlarına tam olarak uymayan cihazlarla geliştirilmiş uyumluluk. Sorunları çözmek için Kea artık seçenek listesinin en başında DHCPv4 mesaj türü bilgilerini gönderiyor, ana bilgisayar adlarının farklı gösterimlerini yönetiyor, boş bir ana bilgisayar adının iletimini tanıyor ve 0'dan 255'e kadar alt seçenek kodlarının tanımlanmasına izin veriyor;
- DDNS arka plan programı için, doğrudan komut gönderebileceğiniz ve konfigürasyon değişiklikleri yapabileceğiniz ayrı bir kontrol soketi eklenmiştir. Aşağıdaki komutlar desteklenir: build-report, config-get, config-reload, config-set, config-test, config-write, list-komutları, kapatma ve version-get;
- elendi (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), yanlış seçeneklere ve değerlere sahip istekler göndererek hizmet reddine neden olmak (DHCPv4 ve DHCPv6 sunucu işleyicilerinin çökmesine neden olmak) için kullanılabilir. En büyük tehlike sorundur bağlamalar için mem dosyası depolaması için kullanıldığında sunucu işleminin kendi başına yeniden başlatılmasını imkansız hale getirir, dolayısıyla işlemi geri yüklemek için yöneticinin manuel müdahalesi (bağlama veritabanını temizlemek) gerekir.
Kaynak: opennet.ru