Кансорцыум ISC рэліз DHCP-сервера , які ідзе на змену класічнаму ISC DHCP. Зыходныя тэксты праекта пад ліцэнзіяй , замест раней прымяняецца для ISC DHCP ліцэнзіі ISC License.
DHCP-сервер Kea заснаваны на тэхналогіях BIND 10 і з выкарыстаннем модульнай архітэктуры, якая разумее разбіццё функцыянальнасці на розныя працэсы-апрацоўшчыкі. Прадукт уключае ў сябе поўнафункцыянальную рэалізацыю сервера з падтрымкай пратаколаў DHCPv4 і DHCPv6, здольную замяніць сабой ISC DHCP. У Kea убудаваны сродкі дынамічнага абнаўлення DNS-зон (Dynamic DNS), падтрымліваюцца механізмы выяўлення сервераў, прызначэнні адрасоў, абнаўленні і перападлучэнні, абслугоўвання інфармацыйных запытаў, рэзерваванні адрасоў для хастоў і PXE-загрузкі. У рэалізацыі DHCPv6 дадаткова прадугледжана магчымасць дэлегавання прэфіксаў. Для ўзаемадзеяння з вонкавымі прыкладаннямі прадастаўляецца спецыяльны API. Магчыма абнаўленне канфігурацыі на лета без перазапуску сервера.
Інфармацыя аб выдзеленых адрасах і параметрах кліентаў можа захоўвацца ў розных тыпах сховішчаў - у цяперашні час прадастаўляюцца бэкэнды для захоўвання ў файлах CSV, СКБД MySQL, Apache Cassandra і PostgreSQL. Параметры рэзервавання хастоў могуць быць зададзены ў файле канфігурацыі ў фармаце JSON ці ў выглядзе табліцы ў MySQL і PostgreSQL. У склад уваходзіць прыладу perfdhcp для вымярэння прадукцыйнасці сервера DHCP і кампаненты для збору статыстыкі. Kea дэманструе нядрэнную прадукцыйнасць, напрыклад, пры выкарыстанні бэкеда MySQL сервер можа выканаць 1000 прысваенняў адрасоў у секунду (каля 4000 пакетаў у секунду), а пры выкарыстанні бэкенда memfile прадукцыйнасць дасягае 7500 прысваенняў у секунду.
ключавыя у Kea 1.6:
- Рэалізаваны бэкэнд канфігурацыі (CB, Configuration Backend), які дазваляе цэнтралізавана кіраваць наладамі некалькіх сервераў DHCPv4 і DHCPv6. Бэкенд можа прымяняцца для захоўвання большасці налад Kea, уключаючы глабальныя параметры, інфармацыю аб агульных сетках, падсетках, опцыях, пулах і вызначэннях опцый. Замест захоўвання ўсіх гэтых налад у лакальным файле канфігурацыі, яны зараз могуць размяшчацца ў вонкавай базе дадзеных. Пры гэтым магчыма азначэнне праз CB не ўсіх, а часткі налад з накладаннем параметраў з вонкавай БД і лакальных файлаў канфігурацыі (напрыклад, у лакальных файлах могуць быць пакінутыя налады сеткавых інтэрфейсаў).
З СКБД для захоўвання канфігурацыі пакуль падтрымліваецца толькі MySQL (для захоўвання баз прысваення адрасоў (leases) могуць выкарыстоўвацца MySQL, PostgreSQL і Cassandra, а для рэзервавання хастоў MySQL і PostgreSQL). Канфігурацыя ў БД можа змяняцца як праз прамы зварот да СКБД, так і праз спецыяльна падрыхтаваныя бібліятэкі-праслойкі, якія прадстаўляюць тыпавы набор каманд для кіравання канфігурацыяй, такія як даданне і выдаленне параметраў, прывязак, DHCP-опцый і падсетак;
- Дададзены новы клас апрацоўшчыкаў "DROP" (усе звязаныя з класам DROP пакеты адразу адкідаюцца), які можа быць выкарыстаны для адкідвання непажаданага трафіку, напрыклад, пэўных тыпаў DHCP-паведамленняў;
- Дададзены новыя параметры max-lease-time і min-lease-time, якія дазваляюць вызначыць час жыцця прывязкі адрасу да кліента (lease) не ў форме цвёрда зададзенага значэння, а ў выглядзе дапушчальнага дыяпазону;
- Палепшана сумяшчальнасць з прыладамі, якія не цалкам выконваюць стандарты для DHCP. Для абыходу праблем Kea зараз адпраўляе інфармацыю аб тыпе паведамлення DHCPv4 у самым пачатку спісу опцый, апрацоўвае розныя ўяўленні імёнаў хастоў, распазнае перадачу пустога імя хаста і дазваляе вызначаць субопцыі з кодамі з 0 па 255;
- Для дэмана DDNS дададзены асобны кіраўнік сокет, праз які можна наўпрост перадаваць каманды і ўносіць змену ў канфігурацыю. Падтрымліваюцца наступныя каманды: build-report, config-get, config-reload, config-set, config-test, config-write, list-commands, shutdown і version-get;
- Ухілены (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), якія могуць быць выкарыстаны для здзяйснення адмовы ў абслугоўванні (выклік краху серверных апрацоўшчыкаў DHCPv4 і DHCPv6) праз адпраўку запытаў з некарэктнымі опцыямі і значэннямі. Найбольшую небяспеку ўяўляе праблема , якая ў выпадку выкарыстання для прывязак сховішчы memfile, прыводзіць да немагчымасці самастойнага перазапуску сервернага працэсу, таму для аднаўлення працы патрабуецца ручное ўмяшанне адміністратара (чыстка базы прывязак).
Крыніца: opennet.ru