ເຊີບເວີ DHCP Kea 1.6, ພັດທະນາໂດຍສະມາຄົມ ISC, ໄດ້ຖືກເຜີຍແຜ່ແລ້ວ

ສະມາຄົມ ISC ຈັດພີມມາ ການປ່ອຍເຄື່ອງແມ່ຂ່າຍ DHCP ເຄ 1.6.0, ແທນ ISC DHCP ຄລາສສິກ. ແຫຼ່ງໂຄງການ ແຜ່​ກະ​ຈາຍ​ເຊື້ອ ພາຍໃຕ້ໃບອະນຸຍາດ Mozilla Public License (MPL) 2.0, ແທນທີ່ຈະເປັນໃບອະນຸຍາດ ISC ທີ່ໃຊ້ໃນເມື່ອກ່ອນສໍາລັບ ISC DHCP.

ເຊີບເວີ Kea DHCP ແມ່ນອີງໃສ່ BIND 10 ແລະ ກໍ່ສ້າງ ການ​ນໍາ​ໃຊ້​ສະ​ຖາ​ປັດ​ຕະ​ຍະ​ການ modular​, ຊຶ່ງ​ຫມາຍ​ຄວາມ​ວ່າ​ການ​ແບ່ງ​ປະ​ຕິ​ບັດ​ການ​ທໍາ​ງານ​ອອກ​ເປັນ​ຂະ​ບວນ​ການ​ຂອງ​ໂຮງ​ງານ​ຜະ​ລິດ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​. ຜະລິດຕະພັນປະກອບມີການປະຕິບັດເຊີຟເວີທີ່ມີລັກສະນະເຕັມທີ່ໂດຍສະຫນັບສະຫນູນໂປໂຕຄອນ DHCPv4 ແລະ DHCPv6, ສາມາດປ່ຽນແທນ ISC DHCP. Kea ມີເຄື່ອງມືໃນຕົວສໍາລັບການປັບປຸງເຂດ DNS ແບບເຄື່ອນໄຫວ (Dynamic DNS), ສະຫນັບສະຫນູນກົນໄກສໍາລັບການຄົ້ນພົບເຄື່ອງແມ່ຂ່າຍ, ການກໍານົດທີ່ຢູ່, ການປັບປຸງແລະການເຊື່ອມຕໍ່ຄືນໃຫມ່, ການຮ້ອງຂໍຂໍ້ມູນການບໍລິການ, ການຈອງທີ່ຢູ່ສໍາລັບເຈົ້າພາບ, ແລະການບູດ PXE. ການປະຕິບັດ DHCPv6 ນອກຈາກນັ້ນຍັງສະຫນອງຄວາມສາມາດໃນການມອບຫມາຍຄໍານໍາຫນ້າ. API ພິເສດແມ່ນສະໜອງໃຫ້ເພື່ອໂຕ້ຕອບກັບແອັບພລິເຄຊັນພາຍນອກ. ມັນເປັນໄປໄດ້ທີ່ຈະປັບປຸງການຕັ້ງຄ່າໃນທັນທີໂດຍບໍ່ຕ້ອງເປີດເຄື່ອງແມ່ຂ່າຍໃຫມ່.

ຂໍ້ມູນກ່ຽວກັບການຈັດສັນທີ່ຢູ່ແລະຕົວກໍານົດການລູກຄ້າສາມາດຖືກເກັບໄວ້ໃນປະເພດການເກັບຮັກສາທີ່ແຕກຕ່າງກັນ - ປະຈຸບັນ backends ໄດ້ຖືກສະຫນອງໃຫ້ສໍາລັບການເກັບຮັກສາໃນໄຟລ໌ CSV, MySQL DBMS, Apache Cassandra ແລະ PostgreSQL. ຕົວກໍານົດການຈອງເຈົ້າພາບສາມາດຖືກລະບຸໄວ້ໃນໄຟລ໌ການຕັ້ງຄ່າໃນຮູບແບບ JSON ຫຼືເປັນຕາຕະລາງໃນ MySQL ແລະ PostgreSQL. ມັນປະກອບມີເຄື່ອງມື perfdhcp ສໍາລັບການວັດແທກປະສິດທິພາບຂອງເຄື່ອງແມ່ຂ່າຍ DHCP ແລະອົງປະກອບສໍາລັບການລວບລວມສະຖິຕິ. Kea ສະແດງໃຫ້ເຫັນເຖິງການປະຕິບັດທີ່ດີ, ຕົວຢ່າງ, ເມື່ອໃຊ້ backend MySQL, ເຄື່ອງແມ່ຂ່າຍສາມາດປະຕິບັດການມອບຫມາຍທີ່ຢູ່ 1000 ຕໍ່ວິນາທີ (ປະມານ 4000 ແພັກເກັດຕໍ່ວິນາທີ), ແລະເມື່ອໃຊ້ backend memfile, ການປະຕິບັດໄດ້ເຖິງ 7500 ມອບຫມາຍຕໍ່ວິນາທີ.

ກະແຈ ການປັບປຸງ ໃນ Kea 1.6:

• Backend ການຕັ້ງຄ່າ (CB, Configuration Backend) ໄດ້ຖືກປະຕິບັດ, ຊ່ວຍໃຫ້ທ່ານສາມາດຈັດການການຕັ້ງຄ່າຂອງເຄື່ອງແມ່ຂ່າຍ DHCPv4 ແລະ DHCPv6 ຫຼາຍສູນກາງ. backend ສາມາດຖືກນໍາໃຊ້ເພື່ອເກັບຮັກສາການຕັ້ງຄ່າ Kea ສ່ວນໃຫຍ່, ລວມທັງການຕັ້ງຄ່າທົ່ວໂລກ, ເຄືອຂ່າຍທີ່ແບ່ງປັນ, subnets, ທາງເລືອກ, pools, ແລະຄໍານິຍາມທາງເລືອກ. ແທນທີ່ຈະເກັບຮັກສາການຕັ້ງຄ່າເຫຼົ່ານີ້ທັງຫມົດໃນໄຟລ໌ການຕັ້ງຄ່າທ້ອງຖິ່ນ, ພວກເຂົາສາມາດຖືກຈັດໃສ່ໃນຖານຂໍ້ມູນພາຍນອກ. ໃນກໍລະນີນີ້, ມັນເປັນໄປໄດ້ທີ່ຈະກໍານົດບໍ່ແມ່ນທັງຫມົດ, ແຕ່ບາງການຕັ້ງຄ່າຜ່ານ CB, overlaying parameters ຈາກຖານຂໍ້ມູນພາຍນອກແລະໄຟລ໌ການຕັ້ງຄ່າທ້ອງຖິ່ນ (ຕົວຢ່າງ, ການຕັ້ງຄ່າການໂຕ້ຕອບເຄືອຂ່າຍສາມາດຖືກປະໄວ້ໃນໄຟລ໌ທ້ອງຖິ່ນ).

  ຂອງ DBMSs ສໍາລັບການເກັບຮັກສາການຕັ້ງຄ່າ, ພຽງແຕ່ MySQL ໄດ້ຮັບການສະຫນັບສະຫນູນ (MySQL, PostgreSQL ແລະ Cassandra ສາມາດນໍາໃຊ້ເພື່ອເກັບຖານຂໍ້ມູນການມອບຫມາຍທີ່ຢູ່ (ເຊົ່າ), ແລະ MySQL ແລະ PostgreSQL ສາມາດນໍາໃຊ້ເພື່ອຈອງເຈົ້າພາບ). ການຕັ້ງຄ່າໃນຖານຂໍ້ມູນສາມາດປ່ຽນແປງໄດ້ໂດຍຜ່ານການເຂົ້າເຖິງໂດຍກົງກັບ DBMS ຫຼືຜ່ານຫ້ອງສະຫມຸດຊັ້ນທີ່ກະກຽມພິເສດທີ່ສະຫນອງຊຸດຄໍາສັ່ງມາດຕະຖານສໍາລັບການຄຸ້ມຄອງການຕັ້ງຄ່າເຊັ່ນການເພີ່ມແລະລຶບພາລາມິເຕີ, ການຜູກມັດ, ທາງເລືອກ DHCP ແລະເຄືອຂ່າຍຍ່ອຍ;

• ເພີ່ມຫ້ອງຮຽນຕົວຈັດການ "DROP" ໃຫມ່ (ທຸກແພັກເກັດທີ່ກ່ຽວຂ້ອງກັບຊັ້ນຮຽນ DROP ຖືກລຸດລົງທັນທີ), ເຊິ່ງສາມາດນໍາໃຊ້ເພື່ອລຸດການຈະລາຈອນທີ່ບໍ່ຕ້ອງການ, ຕົວຢ່າງ, ບາງປະເພດຂອງຂໍ້ຄວາມ DHCP;
• ຕົວກໍານົດການໃຫມ່ max-lease-time ແລະ min-lease-time ໄດ້ຖືກເພີ່ມ, ຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດອາຍຸຂອງທີ່ຢູ່ທີ່ຜູກມັດກັບລູກຄ້າ (ເຊົ່າ) ບໍ່ແມ່ນຢູ່ໃນຮູບແບບຂອງຄ່າ hard-coded, ແຕ່ໃນຮູບແບບຂອງ. ລະດັບທີ່ຍອມຮັບ;
• ປັບປຸງຄວາມເຂົ້າກັນໄດ້ກັບອຸປະກອນທີ່ບໍ່ປະຕິບັດຕາມມາດຕະຖານ DHCP ຢ່າງສົມບູນ. ເພື່ອເຮັດວຽກກ່ຽວກັບບັນຫາ, Kea ຕອນນີ້ສົ່ງຂໍ້ມູນປະເພດຂໍ້ຄວາມ DHCPv4 ໃນຕອນຕົ້ນຂອງບັນຊີລາຍຊື່ທາງເລືອກ, ຈັດການກັບການເປັນຕົວແທນທີ່ແຕກຕ່າງກັນຂອງ hostnames, ຮັບຮູ້ການສົ່ງຂອງ hostname ຫວ່າງເປົ່າ, ແລະອະນຸຍາດໃຫ້ລະຫັດ suboption 0 ຫາ 255 ຖືກກໍານົດ;
• ເຕົ້າຮັບການຄວບຄຸມແຍກຕ່າງຫາກໄດ້ຖືກເພີ່ມສໍາລັບ daemon 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) ໂດຍການສົ່ງຄໍາຮ້ອງຂໍທີ່ມີທາງເລືອກແລະຄ່າທີ່ບໍ່ຖືກຕ້ອງ. ອັນຕະລາຍທີ່ສຸດແມ່ນບັນຫາ CVE-2019-6474, ເຊິ່ງ, ຖ້າການເກັບຮັກສາ memfile ຖືກນໍາໃຊ້ສໍາລັບການຜູກມັດ, ເຮັດໃຫ້ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະ restart ຂະບວນການເຊີຟເວີດ້ວຍຕົວມັນເອງ, ດັ່ງນັ້ນການແຊກແຊງຄູ່ມືໂດຍຜູ້ເບິ່ງແຍງລະບົບ (ທໍາຄວາມສະອາດຖານຂໍ້ມູນການຜູກມັດ) ແມ່ນຈໍາເປັນເພື່ອຟື້ນຟູການດໍາເນີນງານ.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru