ລະວັງຊ່ອງໂຫວ່ທີ່ພາໃຫ້ການເຮັດວຽກຮອບ. ສ່ວນທີ 1: FragmentSmack/SegmentSmack

ສະບາຍດີທຸກຄົນ! ຂ້ອຍຊື່ Dmitry Samsonov, ຂ້ອຍເຮັດວຽກເປັນຜູ້ບໍລິຫານລະບົບຊັ້ນນໍາຢູ່ Odnoklassniki. ພວກເຮົາມີຫຼາຍກວ່າ 7 ພັນເຊີບເວີ, 11 ພັນກ່ອງບັນຈຸຢູ່ໃນເມຄຂອງພວກເຮົາ ແລະ 200 ແອັບພລິເຄຊັນ, ເຊິ່ງໃນການຕັ້ງຄ່າຕ່າງໆປະກອບເປັນ 700 ກຸ່ມທີ່ແຕກຕ່າງກັນ. ເຊີບເວີສ່ວນໃຫຍ່ແລ່ນ CentOS 7.
ໃນວັນທີ 14 ສິງຫາ 2018, ຂໍ້ມູນກ່ຽວກັບຊ່ອງໂຫວ່ FragmentSmack ໄດ້ຖືກເຜີຍແຜ່
(CVE-2018-5391) ແລະ SegmentSmack (CVE-2018-5390). ເຫຼົ່ານີ້ແມ່ນຊ່ອງໂຫວ່ທີ່ມີ vector attack ເຄືອຂ່າຍ ແລະຄະແນນສູງພໍສົມຄວນ (7.5), ເຊິ່ງໄພຂົ່ມຂູ່ຕໍ່ການປະຕິເສດການບໍລິການ (DoS) ເນື່ອງຈາກການໝົດຊັບພະຍາກອນ (CPU). ການແກ້ໄຂ kernel ສໍາລັບ FragmentSmack ບໍ່ໄດ້ຖືກສະເຫນີໃນເວລານັ້ນ, ນອກຈາກນັ້ນ, ມັນໄດ້ອອກມາຫຼາຍກວ່າການເຜີຍແຜ່ຂໍ້ມູນກ່ຽວກັບຄວາມອ່ອນແອ. ເພື່ອລົບລ້າງ SegmentSmack, ມັນໄດ້ຖືກແນະນໍາໃຫ້ປັບປຸງ kernel. ຊຸດການປັບປຸງຕົວມັນເອງໄດ້ຖືກປ່ອຍອອກມາໃນມື້ດຽວກັນ, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນການຕິດຕັ້ງມັນ.
ບໍ່, ພວກເຮົາບໍ່ໄດ້ຕໍ່ຕ້ານການອັບເດດ kernel ເລີຍ! ຢ່າງໃດກໍຕາມ, ມີ nuances ...

ພວກເຮົາປັບປຸງ kernel ໃນການຜະລິດແນວໃດ

ໂດຍທົ່ວໄປ, ບໍ່ມີຫຍັງສັບສົນ:

1. ດາວໂຫລດແພັກເກດ;
2. ຕິດຕັ້ງພວກມັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຈໍານວນຫນຶ່ງ (ລວມທັງເຄື່ອງແມ່ຂ່າຍທີ່ໂຮດເມຄຂອງພວກເຮົາ);
3. ໃຫ້ແນ່ໃຈວ່າບໍ່ມີຫຍັງແຕກ;
4. ໃຫ້ແນ່ໃຈວ່າການຕັ້ງຄ່າ kernel ມາດຕະຖານທັງຫມົດຖືກນໍາໃຊ້ໂດຍບໍ່ມີຂໍ້ຜິດພາດ;
5. ລໍຖ້າສອງສາມມື້;
6. ກວດສອບການປະຕິບັດຂອງເຄື່ອງແມ່ຂ່າຍ;
7. ສະຫຼັບການນຳໃຊ້ເຊີບເວີໃໝ່ໄປຫາ kernel ໃໝ່;
8. ປັບປຸງເຄື່ອງແມ່ຂ່າຍທັງຫມົດໂດຍສູນຂໍ້ມູນ (ສູນຂໍ້ມູນຫນຶ່ງຄັ້ງເພື່ອຫຼຸດຜ່ອນຜົນກະທົບຕໍ່ຜູ້ໃຊ້ໃນກໍລະນີທີ່ມີບັນຫາ);
9. ຣີບູດເຊີບເວີທັງໝົດ.

ເຮັດເລື້ມຄືນສໍາລັບທຸກສາຂາຂອງແກ່ນທີ່ພວກເຮົາມີ. ໃນປັດຈຸບັນມັນແມ່ນ:

• Stock CentOS 7 3.10 - ສໍາລັບເຄື່ອງແມ່ຂ່າຍປົກກະຕິຫຼາຍທີ່ສຸດ;
• Vanilla 4.19 - ສໍາລັບຂອງພວກເຮົາ one-cloud clouds, ເນື່ອງຈາກວ່າພວກເຮົາຕ້ອງການ BFQ, BBR, ແລະອື່ນໆ;
• Elrepo kernel-ml 5.2 - ສໍາລັບ ຜູ້ຈັດຈໍາຫນ່າຍ loaded ສູງ, ເນື່ອງຈາກວ່າ 4.19 ຖືກນໍາໃຊ້ເພື່ອປະຕິບັດຕົວບໍ່ຫມັ້ນຄົງ, ແຕ່ລັກສະນະດຽວກັນແມ່ນຈໍາເປັນ.

ດັ່ງທີ່ເຈົ້າອາດຄາດເດົາໄດ້, ການປິດເປີດເຄື່ອງເຊີບເວີຫຼາຍພັນໜ່ວຍຄືນໃໝ່ໃຊ້ເວລາດົນທີ່ສຸດ. ເນື່ອງຈາກບໍ່ແມ່ນຊ່ອງໂຫວ່ທັງໝົດທີ່ສຳຄັນສຳລັບທຸກເຊີບເວີ, ພວກເຮົາພຽງແຕ່ປິດເປີດເຄື່ອງທີ່ສາມາດເຂົ້າເຖິງໄດ້ໂດຍກົງຈາກອິນເຕີເນັດ. ຢູ່ໃນຄລາວ, ເພື່ອບໍ່ຈໍາກັດຄວາມຍືດຫຍຸ່ນ, ພວກເຮົາບໍ່ໄດ້ເຊື່ອມຕໍ່ກ່ອງບັນຈຸທີ່ສາມາດເຂົ້າເຖິງພາຍນອກກັບເຄື່ອງແມ່ຂ່າຍສ່ວນບຸກຄົນດ້ວຍແກ່ນໃຫມ່, ແຕ່ reboot hosts ທັງຫມົດໂດຍບໍ່ມີຂໍ້ຍົກເວັ້ນ. ໂຊກດີ, ຂັ້ນຕອນທີ່ນັ້ນແມ່ນງ່າຍດາຍກວ່າກັບເຄື່ອງແມ່ຂ່າຍປົກກະຕິ. ຕົວຢ່າງ, ຕູ້ຄອນເທນເນີທີ່ບໍ່ມີລັດສາມາດຍ້າຍໄປຫາເຄື່ອງແມ່ຂ່າຍອື່ນໃນລະຫວ່າງການປິດເປີດໃໝ່.

ຢ່າງໃດກໍ່ຕາມ, ຍັງມີວຽກຫຼາຍ, ແລະມັນອາດຈະໃຊ້ເວລາຫຼາຍອາທິດ, ແລະຖ້າມີບັນຫາໃດໆກັບຮຸ່ນໃຫມ່, ສູງເຖິງຫຼາຍເດືອນ. ຜູ້ໂຈມຕີເຂົ້າໃຈເລື່ອງນີ້ດີ, ສະນັ້ນພວກເຂົາຕ້ອງການແຜນການ B.

FragmentSmack/SegmentSmack. ການແກ້ໄຂບັນຫາ

ໂຊກດີ, ສໍາລັບບາງຊ່ອງໂຫວ່ເຊັ່ນແຜນ B ມີຢູ່, ແລະມັນເອີ້ນວ່າ Workaround. ສ່ວນຫຼາຍແລ້ວ, ນີ້ແມ່ນການປ່ຽນແປງໃນການຕັ້ງຄ່າ kernel/application ທີ່ສາມາດຫຼຸດຜ່ອນຜົນກະທົບທີ່ເປັນໄປໄດ້ ຫຼືລົບລ້າງການຂູດຮີດຊ່ອງໂຫວ່ທັງໝົດ.

ໃນກໍລະນີຂອງ FragmentSmack / SegmentSmack ໄດ້ຖືກສະເຫນີ ການ​ແກ້​ໄຂ​ດັ່ງ​ນີ້​:

«ທ່ານສາມາດປ່ຽນຄ່າເລີ່ມຕົ້ນຂອງ 4MB ແລະ 3MB ໃນ net.ipv4.ipfrag_high_thresh ແລະ net.ipv4.ipfrag_low_thresh (ແລະຄູ່ຮ່ວມງານຂອງພວກມັນສໍາລັບ ipv6 net.ipv6.ipfrag_high_thresh ແລະ net.ipv6.ipfrag_low_thresh) ເປັນ 256 k. ຕ່ໍາກວ່າ. ການ​ທົດ​ສອບ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ການ​ຫຼຸດ​ລົງ​ຂະ​ຫນາດ​ນ້ອຍ​ທີ່​ສໍາ​ຄັນ​ໃນ​ການ​ນໍາ​ໃຊ້ CPU ໃນ​ລະ​ຫວ່າງ​ການ​ໂຈມ​ຕີ​ຂຶ້ນ​ກັບ​ຮາດ​ແວ​, ການ​ຕັ້ງ​ຄ່າ​, ແລະ​ເງື່ອນ​ໄຂ​. ຢ່າງໃດກໍ່ຕາມ, ອາດຈະມີຜົນກະທົບດ້ານການປະຕິບັດບາງຢ່າງເນື່ອງຈາກ ipfrag_high_thresh=192 bytes, ເນື່ອງຈາກວ່າພຽງແຕ່ສອງຊິ້ນ 262144K ສາມາດເຂົ້າກັບແຖວການປະກອບຄືນໃຫມ່ໃນເວລາດຽວ. ຕົວຢ່າງ, ມີຄວາມສ່ຽງທີ່ແອັບພລິເຄຊັນທີ່ເຮັດວຽກກັບແພັກເກັດ UDP ຂະຫນາດໃຫຍ່ຈະແຕກ".

ຕົວກໍານົດການດ້ວຍຕົນເອງ ໃນເອກະສານ kernel ອະ​ທິ​ບາຍ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ipfrag_high_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments before the kernel
    begins to remove incomplete fragment queues to free up resources.
    The kernel still accepts new fragments for defragmentation.

ພວກເຮົາບໍ່ມີ UDPs ຂະຫນາດໃຫຍ່ໃນການບໍລິການການຜະລິດ. ບໍ່ມີການຈະລາຈອນແຍກຢູ່ໃນ LAN; ມີການຈາລະຈອນທີ່ແຕກແຍກຢູ່ໃນ WAN, ແຕ່ບໍ່ສໍາຄັນ. ບໍ່​ມີ​ສັນ​ຍານ​ທີ່​ບໍ່​ມີ - ທ່ານ​ສາ​ມາດ​ມ້ວນ​ອອກ Workaround ໄດ້​!

FragmentSmack/SegmentSmack. ເລືອດທໍາອິດ

ບັນຫາທໍາອິດທີ່ພວກເຮົາພົບແມ່ນວ່າ cloud containers ບາງຄັ້ງໃຊ້ການຕັ້ງຄ່າໃຫມ່ພຽງແຕ່ບາງສ່ວນ (ພຽງແຕ່ ipfrag_low_thresh), ແລະບາງຄັ້ງບໍ່ໄດ້ນໍາໃຊ້ພວກມັນທັງຫມົດ - ພວກເຂົາພຽງແຕ່ crashed ໃນຕອນເລີ່ມຕົ້ນ. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະສ້າງບັນຫາຄືນໃໝ່ໄດ້ຢ່າງໝັ້ນຄົງ (ການຕັ້ງຄ່າທັງໝົດຖືກນຳໃຊ້ດ້ວຍຕົນເອງໂດຍບໍ່ມີຄວາມຫຍຸ້ງຍາກໃດໆ). ຄວາມເຂົ້າໃຈວ່າເປັນຫຍັງຕູ້ຄອນເທນເນີ crash ໃນຕອນເລີ່ມຕົ້ນກໍ່ບໍ່ແມ່ນເລື່ອງງ່າຍ: ບໍ່ພົບຂໍ້ຜິດພາດ. ສິ່ງຫນຶ່ງແມ່ນແນ່ນອນ: ການມ້ວນຄືນການຕັ້ງຄ່າແກ້ໄຂບັນຫາທີ່ມີການຂັດຂືນຕູ້ຄອນເທນເນີ.

ເປັນຫຍັງມັນບໍ່ພຽງພໍທີ່ຈະໃຊ້ Sysctl ໃນໂຮດ? ຕູ້ຄອນເທນເນີອາໃສຢູ່ໃນເຄືອຂ່າຍ Namespace ທີ່ອຸທິດຕົນຂອງຕົນເອງ, ດັ່ງນັ້ນຢ່າງຫນ້ອຍ ສ່ວນຫນຶ່ງຂອງຕົວກໍານົດການເຄືອຂ່າຍ Sysctl ໃນຕູ້ຄອນເທນເນີອາດຈະແຕກຕ່າງຈາກເຈົ້າພາບ.

ການຕັ້ງຄ່າ Sysctl ຖືກນຳໃຊ້ໃນກ່ອງບັນຈຸແນວໃດ? ເນື່ອງຈາກຕູ້ຄອນເທນເນີຂອງພວກເຮົາບໍ່ມີສິດທິພິເສດ, ທ່ານຈະບໍ່ສາມາດປ່ຽນການຕັ້ງຄ່າ Sysctl ໃດໆໂດຍການເຂົ້າໄປໃນຕູ້ຄອນເທນເນີນັ້ນເອງ - ທ່ານພຽງແຕ່ບໍ່ມີສິດພຽງພໍ. ເພື່ອດໍາເນີນການ containers, cloud ຂອງພວກເຮົາໃນເວລານັ້ນໄດ້ໃຊ້ Docker (ຕອນນີ້ podman). ພາລາມິເຕີຂອງບັນຈຸໃຫມ່ໄດ້ຖືກສົ່ງກັບ Docker ຜ່ານ API, ລວມທັງການຕັ້ງຄ່າ Sysctl ທີ່ຈໍາເປັນ.
ໃນຂະນະທີ່ຄົ້ນຫາຜ່ານຮຸ່ນ, ມັນໄດ້ຫັນອອກວ່າ Docker API ບໍ່ໄດ້ສົ່ງຄືນຂໍ້ຜິດພາດທັງຫມົດ (ຢ່າງຫນ້ອຍໃນຮຸ່ນ 1.10). ເມື່ອພວກເຮົາພະຍາຍາມເລີ່ມຕົ້ນຕູ້ຄອນເທນເນີຜ່ານ "ການແລ່ນ docker", ໃນທີ່ສຸດພວກເຮົາໄດ້ເຫັນບາງສິ່ງບາງຢ່າງຢ່າງຫນ້ອຍ:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

ຄ່າພາຣາມິເຕີບໍ່ຖືກຕ້ອງ. ແຕ່ເປັນຫຍັງ? ແລະເປັນຫຍັງມັນບໍ່ຖືກຕ້ອງພຽງແຕ່ບາງຄັ້ງ? ມັນໄດ້ຫັນອອກວ່າ Docker ບໍ່ໄດ້ຮັບປະກັນຄໍາສັ່ງທີ່ພາລາມິເຕີ Sysctl ຖືກນໍາໃຊ້ (ຮຸ່ນທີ່ທົດສອບຫຼ້າສຸດແມ່ນ 1.13.1), ດັ່ງນັ້ນບາງຄັ້ງ ipfrag_high_thresh ພະຍາຍາມຕັ້ງເປັນ 256K ເມື່ອ ipfrag_low_thresh ຍັງເປັນ 3M, ນັ້ນແມ່ນ, ຂອບເຂດຈໍາກັດເທິງແມ່ນຕ່ໍາ. ເກີນຂອບເຂດຈໍາກັດຕ່ໍາ, ເຊິ່ງນໍາໄປສູ່ຄວາມຜິດພາດ.

ໃນ​ເວ​ລາ​ນັ້ນ​, ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ກົນ​ໄກ​ຂອງ​ຕົນ​ເອງ​ສໍາ​ລັບ​ການ reconfigure container ຫຼັງ​ຈາກ​ການ​ເລີ່ມ​ຕົ້ນ (freezing the container ຫຼັງ​ຈາກ​ freezer ກຸ່ມ ແລະປະຕິບັດຄໍາສັ່ງໃນ namespace ຂອງ container ຜ່ານ ip netns), ແລະພວກເຮົາຍັງໄດ້ເພີ່ມການຂຽນຕົວກໍານົດການ Sysctl ໃນສ່ວນນີ້. ບັນຫາໄດ້ຖືກແກ້ໄຂ.

FragmentSmack/SegmentSmack. ເລືອດທຳອິດ 2

ກ່ອນທີ່ພວກເຮົາຈະມີເວລາທີ່ຈະເຂົ້າໃຈການນໍາໃຊ້ Workaround ໃນເມຄ, ຄໍາຮ້ອງທຸກທີ່ຫາຍາກຄັ້ງທໍາອິດຈາກຜູ້ໃຊ້ໄດ້ເລີ່ມຕົ້ນມາຮອດ. ໃນເວລານັ້ນ, ຫຼາຍອາທິດໄດ້ຜ່ານໄປນັບຕັ້ງແຕ່ການເລີ່ມຕົ້ນຂອງການນໍາໃຊ້ Workaround ໃນເຄື່ອງແມ່ຂ່າຍທໍາອິດ. ການສືບສວນໃນເບື້ອງຕົ້ນໄດ້ສະແດງໃຫ້ເຫັນວ່າການຮ້ອງທຸກໄດ້ຖືກຮັບຕໍ່ກັບການບໍລິການສ່ວນບຸກຄົນ, ແລະບໍ່ແມ່ນເຄື່ອງແມ່ຂ່າຍທັງຫມົດຂອງການບໍລິການເຫຼົ່ານີ້. ບັນຫາໄດ້ກາຍເປັນຄວາມບໍ່ແນ່ນອນທີ່ສຸດອີກເທື່ອຫນຶ່ງ.

ກ່ອນອື່ນ ໝົດ, ແນ່ນອນ, ພວກເຮົາພະຍາຍາມມ້ວນຄືນການຕັ້ງຄ່າ Sysctl, ແຕ່ນີ້ບໍ່ມີຜົນຫຍັງເລີຍ. ການຫມູນໃຊ້ຕ່າງໆກັບເຄື່ອງແມ່ຂ່າຍແລະການຕັ້ງຄ່າແອັບພລິເຄຊັນບໍ່ໄດ້ຊ່ວຍທັງສອງ. Reboot ຊ່ວຍໄດ້. Rebooting Linux ແມ່ນຜິດທໍາມະຊາດຍ້ອນວ່າມັນເປັນເລື່ອງປົກກະຕິສໍາລັບ Windows ໃນສະໄຫມກ່ອນ. ຢ່າງໃດກໍຕາມ, ມັນໄດ້ຊ່ວຍ, ແລະພວກເຮົາໄດ້ຂຽນມັນເຖິງ "ຄວາມຜິດພາດຂອງແກ່ນ" ເມື່ອນໍາໃຊ້ການຕັ້ງຄ່າໃຫມ່ໃນ Sysctl. ມັນ frovolous ແນວໃດ ...

ສາມອາທິດຕໍ່ມາ ບັນຫາກໍ່ເກີດຂຶ້ນອີກ. ການຕັ້ງຄ່າຂອງເຊີບເວີເຫຼົ່ານີ້ແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ: Nginx ຢູ່ໃນໂໝດພຣັອກຊີ/ຕົວດຸ່ນດ່ຽງ. ບໍ່ມີການຈະລາຈອນຫຼາຍ. ບັນທຶກການແນະນໍາໃຫມ່: ຈໍານວນ 504 ຂໍ້ຜິດພາດກ່ຽວກັບລູກຄ້າແມ່ນເພີ່ມຂຶ້ນທຸກໆມື້ (ໝົດເວລາປະຕູ). ເສັ້ນສະແດງສະແດງຈໍານວນ 504 ຂໍ້ຜິດພາດຕໍ່ມື້ສໍາລັບການບໍລິການນີ້:

ຂໍ້ຜິດພາດທັງຫມົດແມ່ນກ່ຽວກັບ backend ດຽວກັນ - ກ່ຽວກັບຫນຶ່ງທີ່ຢູ່ໃນເມຄ. ເສັ້ນສະແດງການບໍລິໂພກຫນ່ວຍຄວາມຈໍາສໍາລັບຊິ້ນສ່ວນຂອງແພັກເກັດຢູ່ໃນ backend ນີ້ເບິ່ງຄືວ່າ:

ນີ້ແມ່ນຫນຶ່ງໃນການສະແດງອອກທີ່ຊັດເຈນທີ່ສຸດຂອງບັນຫາໃນກາຟຂອງລະບົບປະຕິບັດການ. ໃນຄລາວ, ພຽງແຕ່ໃນເວລາດຽວກັນ, ບັນຫາເຄືອຂ່າຍອື່ນທີ່ມີການຕັ້ງຄ່າ QoS (Traffic Control) ຖືກແກ້ໄຂ. ໃນເສັ້ນສະແດງການບໍລິໂພກຄວາມຊົງຈໍາສໍາລັບຊິ້ນສ່ວນແພັກເກັດ, ມັນເບິ່ງຄືວ່າຄືກັນ:

ການສົມມຸດຕິຖານແມ່ນງ່າຍດາຍ: ຖ້າພວກເຂົາເບິ່ງຄືກັນໃນກາຟ, ຫຼັງຈາກນັ້ນພວກເຂົາມີເຫດຜົນດຽວກັນ. ຍິ່ງໄປກວ່ານັ້ນ, ບັນຫາໃດໆກັບປະເພດຂອງຄວາມຊົງຈໍານີ້ແມ່ນຫາຍາກທີ່ສຸດ.

ໂດຍເນື້ອແທ້ແລ້ວຂອງບັນຫາທີ່ຄົງຄ້າງແມ່ນວ່າພວກເຮົາໄດ້ໃຊ້ຕົວກໍານົດເວລາຊຸດ fq ກັບການຕັ້ງຄ່າເລີ່ມຕົ້ນໃນ QoS. ໂດຍຄ່າເລີ່ມຕົ້ນ, ສໍາລັບການເຊື່ອມຕໍ່ຫນຶ່ງ, ມັນຊ່ວຍໃຫ້ທ່ານສາມາດເພີ່ມ 100 ຊອງໃສ່ແຖວ, ແລະການເຊື່ອມຕໍ່ບາງຢ່າງ, ໃນສະຖານະການຂາດແຄນຊ່ອງທາງ, ໄດ້ເລີ່ມຕົ້ນທີ່ຈະອຸດຕັນແຖວຕໍ່ຄວາມສາມາດ. ໃນກໍລະນີນີ້, ແພັກເກັດຖືກລຸດລົງ. ໃນສະຖິຕິ tc (tc -s qdisc) ມັນສາມາດເຫັນໄດ້ເຊັ່ນນີ້:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
 Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  1024 flows (1021 inactive, 0 throttled)
  0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

“464545 flows_plimit” ແມ່ນແພັກເກັດທີ່ຫຼຸດລົງເນື່ອງຈາກເກີນຂີດຈໍາກັດແຖວຂອງການເຊື່ອມຕໍ່ຫນຶ່ງ, ແລະ “ຫຼຸດລົງ 464545” ແມ່ນຜົນລວມຂອງແພັກເກັດທີ່ຫຼຸດລົງທັງໝົດຂອງຕົວກໍານົດເວລານີ້. ຫຼັງ​ຈາກ​ເພີ່ມ​ຄວາມ​ຍາວ​ຂອງ​ຄິວ​ເປັນ 1 ພັນ​ແລະ restart ຕູ້​ຄອນ​ເທນ​ເນີ​, ບັນ​ຫາ​ໄດ້​ຢຸດ​ເຊົາ​ການ​ເກີດ​ຂຶ້ນ​. ທ່ານສາມາດນັ່ງກັບຄືນໄປບ່ອນແລະດື່ມ smoothie ໄດ້.

FragmentSmack/SegmentSmack. ເລືອດສຸດທ້າຍ

ກ່ອນອື່ນ ໝົດ, ຫຼາຍເດືອນຫຼັງຈາກການປະກາດຄວາມອ່ອນແອໃນ kernel, ການແກ້ໄຂ FragmentSmack ສຸດທ້າຍໄດ້ປາກົດ (ຂ້ອຍຂໍເຕືອນທ່ານວ່າພ້ອມກັບການປະກາດໃນເດືອນສິງຫາ, ການແກ້ໄຂພຽງແຕ່ສໍາລັບ SegmentSmack ໄດ້ຖືກປ່ອຍອອກມາ), ເຊິ່ງເຮັດໃຫ້ພວກເຮົາມີໂອກາດທີ່ຈະປະຖິ້ມ Workaround, ຊຶ່ງເຮັດໃຫ້ພວກເຮົາມີບັນຫາຫຼາຍ. ໃນລະຫວ່າງເວລານີ້, ພວກເຮົາໄດ້ຈັດການການໂອນບາງເຄື່ອງແມ່ຂ່າຍໄປຫາ kernel ໃຫມ່ແລ້ວ, ແລະຕອນນີ້ພວກເຮົາຕ້ອງເລີ່ມຕົ້ນຈາກຈຸດເລີ່ມຕົ້ນ. ເປັນຫຍັງພວກເຮົາປັບປຸງ kernel ໂດຍບໍ່ຕ້ອງລໍຖ້າການແກ້ໄຂ FragmentSmack? ຄວາມຈິງແລ້ວແມ່ນວ່າຂະບວນການປ້ອງກັນຄວາມອ່ອນແອເຫຼົ່ານີ້ກົງກັນ (ແລະລວມເຂົ້າກັນ) ກັບຂະບວນການປັບປຸງ CentOS ຕົວມັນເອງ (ເຊິ່ງໃຊ້ເວລາຫຼາຍກວ່າການປັບປຸງພຽງແຕ່ແກ່ນ). ນອກຈາກນັ້ນ, SegmentSmack ແມ່ນຊ່ອງໂຫວ່ທີ່ເປັນອັນຕະລາຍກວ່າ, ແລະການແກ້ໄຂສໍາລັບມັນປາກົດຂຶ້ນທັນທີ, ດັ່ງນັ້ນມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກຢ່າງໃດກໍ່ຕາມ. ຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາບໍ່ສາມາດອັບເດດ kernel ເທິງ CentOS ໄດ້ງ່າຍໆ ເພາະວ່າຊ່ອງໂຫວ່ FragmentSmack, ທີ່ປາກົດໃນລະຫວ່າງ CentOS 7.5, ໄດ້ຖືກແກ້ໄຂພຽງແຕ່ໃນເວີຊັນ 7.6, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງຕ້ອງຢຸດການອັບເດດເປັນ 7.5 ແລະເລີ່ມຕົ້ນອີກຄັ້ງດ້ວຍການອັບເດດເປັນ 7.6. ແລະນີ້ຍັງເກີດຂຶ້ນ.

ອັນທີສອງ, ຄໍາຮ້ອງທຸກຂອງຜູ້ໃຊ້ທີ່ຫາຍາກກ່ຽວກັບບັນຫາໄດ້ກັບຄືນມາຫາພວກເຮົາ. ຕອນນີ້ພວກເຮົາຮູ້ແລ້ວວ່າພວກເຂົາທັງຫມົດແມ່ນກ່ຽວຂ້ອງກັບການອັບໂຫລດໄຟລ໌ຈາກລູກຄ້າໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາບາງອັນ. ຍິ່ງໄປກວ່ານັ້ນ, ຈໍານວນການອັບໂຫລດຈໍານວນນ້ອຍຫຼາຍຈາກມະຫາຊົນທັງຫມົດໄດ້ຜ່ານເຄື່ອງແມ່ຂ່າຍເຫຼົ່ານີ້.

ດັ່ງທີ່ພວກເຮົາຈື່ໄດ້ຈາກເລື່ອງຂ້າງເທິງ, rolling back Sysctl ບໍ່ໄດ້ຊ່ວຍ. Reboot ຊ່ວຍ, ແຕ່ເປັນການຊົ່ວຄາວ.
ຄວາມສົງໃສກ່ຽວກັບ Sysctl ບໍ່ໄດ້ຖືກໂຍກຍ້າຍ, ແຕ່ເວລານີ້ມັນຈໍາເປັນຕ້ອງເກັບກໍາຂໍ້ມູນຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້. ນອກຈາກນີ້ຍັງມີການຂາດຄວາມສາມາດໃນການສ້າງບັນຫາການອັບໂຫລດຄືນໃຫມ່ໃນລູກຄ້າເພື່ອສຶກສາຢ່າງແນ່ນອນກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນ.

ການວິເຄາະສະຖິຕິແລະບັນທຶກທີ່ມີຢູ່ທັງຫມົດບໍ່ໄດ້ເຮັດໃຫ້ພວກເຮົາເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນ. ມີການຂາດຄວາມສາມາດໃນການແຜ່ພັນຢ່າງຮ້າຍແຮງເພື່ອ "ຮູ້ສຶກ" ການເຊື່ອມຕໍ່ສະເພາະ. ສຸດທ້າຍ, ນັກພັດທະນາ, ການນໍາໃຊ້ສະບັບພິເສດຂອງຄໍາຮ້ອງສະຫມັກ, ການຄຸ້ມຄອງເພື່ອບັນລຸການແຜ່ພັນທີ່ຫມັ້ນຄົງຂອງບັນຫາໃນອຸປະກອນການທົດສອບໃນເວລາທີ່ເຊື່ອມຕໍ່ຜ່ານ Wi-Fi. ນີ້​ແມ່ນ​ຄວາມ​ແຕກ​ແຍກ​ໃນ​ການ​ສືບ​ສວນ. ລູກຄ້າເຊື່ອມຕໍ່ກັບ Nginx, ເຊິ່ງ proxyed ກັບ backend, ເຊິ່ງເປັນຄໍາຮ້ອງສະຫມັກ Java ຂອງພວກເຮົາ.

ການສົນທະນາສໍາລັບບັນຫາແມ່ນເປັນແບບນີ້ (ແກ້ໄຂໃນດ້ານ Nginx proxy):

1. ລູກຄ້າ: ຮ້ອງຂໍໃຫ້ໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບການດາວໂຫຼດໄຟລ໌.
2. Java server: ຕອບສະໜອງ.
3. ລູກຄ້າ: ໂພສດ້ວຍໄຟລ໌.
4. ເຊີບເວີ Java: ຜິດພາດ.

ໃນເວລາດຽວກັນ, ເຄື່ອງແມ່ຂ່າຍຂອງ Java ຂຽນໃສ່ບັນທຶກທີ່ 0 bytes ຂອງຂໍ້ມູນໄດ້ຮັບຈາກລູກຄ້າ, ແລະ Nginx proxy ຂຽນວ່າການຮ້ອງຂໍໃຊ້ເວລາຫຼາຍກວ່າ 30 ວິນາທີ (30 ວິນາທີແມ່ນເວລາຫມົດເວລາຂອງຄໍາຮ້ອງສະຫມັກລູກຄ້າ). ເປັນຫຍັງໝົດເວລາ ແລະເປັນຫຍັງ 0 bytes? ຈາກທັດສະນະ HTTP, ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຕາມທີ່ມັນຄວນຈະ, ແຕ່ POST ກັບໄຟລ໌ເບິ່ງຄືວ່າຈະຫາຍໄປຈາກເຄືອຂ່າຍ. ຍິ່ງໄປກວ່ານັ້ນ, ມັນຫາຍໄປລະຫວ່າງລູກຄ້າແລະ Nginx. ມັນເຖິງເວລາທີ່ຈະປະກອບອາວຸດຕົວເອງກັບ Tcpdump! ແຕ່ທໍາອິດທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈການຕັ້ງຄ່າເຄືອຂ່າຍ. Nginx proxy ແມ່ນຢູ່ເບື້ອງຫຼັງ L3 balancer NFware. Tunneling ແມ່ນໃຊ້ເພື່ອຈັດສົ່ງແພັກເກັດຈາກ L3 balancer ໄປຫາເຊີບເວີ, ເຊິ່ງເພີ່ມສ່ວນຫົວຂອງມັນໃສ່ແພັກເກັດ:

ໃນກໍລະນີນີ້, ເຄືອຂ່າຍມາຮອດເຄື່ອງແມ່ຂ່າຍນີ້ໃນຮູບແບບການຈາລະຈອນ Vlan-tagged, ເຊິ່ງຍັງເພີ່ມທົ່ງນາຂອງຕົນເອງໃສ່ແພັກເກັດ:

ແລະການຈະລາຈອນນີ້ຍັງສາມາດແບ່ງອອກໄດ້ (ອັດຕາສ່ວນນ້ອຍໆດຽວກັນຂອງການຈະລາຈອນທີ່ແຕກແຍກທີ່ເຂົ້າມາທີ່ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບການປະເມີນຄວາມສ່ຽງຈາກ Workaround), ເຊິ່ງຍັງມີການປ່ຽນແປງເນື້ອໃນຂອງຫົວຂໍ້:

ອີກເທື່ອ ໜຶ່ງ: ແພັກເກັດຖືກຫຸ້ມດ້ວຍປ້າຍ Vlan, ຫຸ້ມດ້ວຍອຸໂມງ, ແຍກເປັນສ່ວນ. ເພື່ອເຂົ້າໃຈວິທີການນີ້ເກີດຂຶ້ນໄດ້ດີຂຶ້ນ, ໃຫ້ຕິດຕາມເສັ້ນທາງແພັກເກັດຈາກລູກຄ້າໄປຫາ Nginx proxy.

1. ແພັກເກັດໄປຮອດຕົວດຸ່ນດ່ຽງ L3. ສໍາລັບເສັ້ນທາງທີ່ຖືກຕ້ອງພາຍໃນສູນຂໍ້ມູນ, ແພັກເກັດຖືກຫຸ້ມໄວ້ໃນອຸໂມງແລະຖືກສົ່ງໄປຫາບັດເຄືອຂ່າຍ.
2. ເນື່ອງຈາກ packet + tunnel headers ບໍ່ເຫມາະກັບ MTU, packet ໄດ້ຖືກຕັດອອກເປັນ fragments ແລະຖືກສົ່ງໄປຫາເຄືອຂ່າຍ.
3. ສະຫຼັບຫຼັງຈາກ L3 balancer, ເມື່ອໄດ້ຮັບແພັກເກັດ, ເພີ່ມແທັກ Vlan ໃສ່ມັນແລະສົ່ງມັນ.
4. ສະຫຼັບຢູ່ທາງຫນ້າຂອງ Nginx proxy ເຫັນ (ອີງຕາມການຕັ້ງຄ່າພອດ) ທີ່ເຄື່ອງແມ່ຂ່າຍຄາດວ່າຈະມີຊອງ Vlan-encapsulated, ດັ່ງນັ້ນມັນຈະສົ່ງມັນອອກ, ໂດຍບໍ່ມີການຖອນແທັກ Vlan.
5. Linux ເອົາຊິ້ນສ່ວນຂອງແພັກເກັດແຕ່ລະອັນແລະລວມພວກມັນເຂົ້າໄປໃນຊຸດໃຫຍ່ຫນຶ່ງ.
6. ຕໍ່ໄປ, ແພັກເກັດໄປຮອດການໂຕ້ຕອບ Vlan, ບ່ອນທີ່ຊັ້ນທໍາອິດຖືກໂຍກຍ້າຍອອກຈາກມັນ - Vlan encapsulation.
7. Linux ຫຼັງຈາກນັ້ນສົ່ງມັນໄປທີ່ການໂຕ້ຕອບ Tunnel, ບ່ອນທີ່ຊັ້ນອື່ນຖືກໂຍກຍ້າຍອອກຈາກມັນ - Tunnel encapsulation .

ຄວາມຫຍຸ້ງຍາກແມ່ນເພື່ອຜ່ານທັງຫມົດນີ້ເປັນຕົວກໍານົດການ tcpdump.
ໃຫ້ເລີ່ມຕົ້ນຈາກຕອນທ້າຍ: ມີຊຸດ IP ທີ່ສະອາດ (ໂດຍບໍ່ມີສ່ວນຫົວທີ່ບໍ່ຈໍາເປັນ) ຈາກລູກຄ້າ, ມີ vlan ແລະ tunnel encapsulation ເອົາອອກ?

tcpdump host <ip клиента>

ບໍ່, ບໍ່ມີແພັກເກດດັ່ງກ່າວຢູ່ໃນເຊີບເວີ. ດັ່ງນັ້ນບັນຫາຈະຕ້ອງມີກ່ອນຫນ້ານັ້ນ. ມີແພັກເກັດໃດທີ່ມີພຽງແຕ່ Vlan encapsulation ເອົາອອກບໍ?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx ແມ່ນທີ່ຢູ່ IP ຂອງລູກຄ້າໃນຮູບແບບ hex.
32:4 — ທີ່​ຢູ່​ແລະ​ຄວາມ​ຍາວ​ຂອງ​ພາກ​ສະ​ຫນາມ​ທີ່ SCR IP ໄດ້​ຖືກ​ຂຽນ​ໄວ້​ໃນ​ຊອງ Tunnel​.

ທີ່ຢູ່ພາກສະຫນາມຕ້ອງໄດ້ຮັບການຄັດເລືອກໂດຍ brute force, ນັບຕັ້ງແຕ່ໃນອິນເຕີເນັດພວກເຂົາຂຽນກ່ຽວກັບ 40, 44, 50, 54, ແຕ່ບໍ່ມີທີ່ຢູ່ IP ຢູ່ທີ່ນັ້ນ. ທ່ານຍັງສາມາດເບິ່ງຫນຶ່ງຂອງແພັກເກັດໃນ hex (ພາລາມິເຕີ -xx ຫຼື -XX ໃນ tcpdump) ແລະຄິດໄລ່ທີ່ຢູ່ IP ທີ່ທ່ານຮູ້ຈັກ.

ມີຊິ້ນສ່ວນແພັກເກັດທີ່ບໍ່ມີ Vlan ແລະ Tunnel encapsulation ເອົາອອກບໍ?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

magic ນີ້ຈະສະແດງໃຫ້ພວກເຮົາເຫັນຊິ້ນສ່ວນທັງຫມົດ, ລວມທັງອັນສຸດທ້າຍ. ບາງທີ, ສິ່ງດຽວກັນສາມາດຖືກກັ່ນຕອງໂດຍ IP, ແຕ່ຂ້ອຍບໍ່ໄດ້ພະຍາຍາມ, ເພາະວ່າບໍ່ມີຊຸດດັ່ງກ່າວຫຼາຍ, ແລະສິ່ງທີ່ຂ້ອຍຕ້ອງການແມ່ນພົບໄດ້ງ່າຍໃນກະແສທົ່ວໄປ. ນີ້ແມ່ນ:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
    11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
    33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
        0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
        0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
        0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
        0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
        0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
    11.11.11.11 > 22.22.22.22: ip-proto-4
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
        0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
        0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
        0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

ເຫຼົ່ານີ້ແມ່ນສອງຊິ້ນຂອງຊຸດຫນຶ່ງ (ID ດຽວກັນ 53652) ທີ່ມີຮູບຖ່າຍ (ຄໍາວ່າ Exif ແມ່ນເຫັນໄດ້ໃນຊຸດທໍາອິດ). ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າມີການຫຸ້ມຫໍ່ໃນລະດັບນີ້, ແຕ່ບໍ່ແມ່ນຢູ່ໃນຮູບແບບລວມຢູ່ໃນບ່ອນຖິ້ມຂີ້ເຫຍື້ອ, ບັນຫາແມ່ນເຫັນໄດ້ຊັດເຈນກັບການປະກອບ. ສຸດທ້າຍມີເອກະສານຫຼັກຖານ!

ຕົວຖອດລະຫັດແພັກເກັດບໍ່ໄດ້ເປີດເຜີຍບັນຫາໃດໆທີ່ຈະປ້ອງກັນການສ້າງ. ພະຍາຍາມມັນຢູ່ທີ່ນີ້: hpd.gasmi.net. ທໍາອິດ, ເມື່ອທ່ານພະຍາຍາມເອົາບາງສິ່ງບາງຢ່າງຢູ່ທີ່ນັ້ນ, ຕົວຖອດລະຫັດບໍ່ມັກຮູບແບບແພັກເກັດ. ມັນໄດ້ຫັນອອກວ່າມີບາງ octets ພິເສດລະຫວ່າງ Srcmac ແລະ Ethertype (ບໍ່ກ່ຽວຂ້ອງກັບຂໍ້ມູນຊິ້ນສ່ວນ). ຫຼັງຈາກທີ່ເອົາພວກມັນອອກ, ຕົວຖອດລະຫັດເລີ່ມຕົ້ນເຮັດວຽກ. ຢ່າງໃດກໍຕາມ, ມັນບໍ່ໄດ້ສະແດງໃຫ້ເຫັນບັນຫາ.
ສິ່ງໃດກໍ່ຕາມທີ່ຄົນເຮົາເວົ້າ, ບໍ່ມີຫຍັງອີກບໍ່ພົບນອກຈາກ Sysctl ເຫຼົ່ານັ້ນ. ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອຊອກຫາວິທີການກໍານົດເຄື່ອງແມ່ຂ່າຍທີ່ມີບັນຫາເພື່ອເຂົ້າໃຈຂະຫນາດແລະການຕັດສິນໃຈໃນການປະຕິບັດຕໍ່ໄປ. ເຄົາເຕີທີ່ຕ້ອງການໄດ້ຖືກພົບເຫັນຢ່າງໄວວາພຽງພໍ:

netstat -s | grep "packet reassembles failed”

ມັນຍັງຢູ່ໃນ snmpd ພາຍໃຕ້ OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"ຈໍານວນຂອງຄວາມລົ້ມເຫລວທີ່ກວດພົບໂດຍ IP ຂັ້ນຕອນການປະກອບໃຫມ່ (ສໍາລັບເຫດຜົນໃດກໍ່ຕາມ: ໝົດ ເວລາ, ຄວາມຜິດພາດ, ແລະອື່ນໆ).

ໃນບັນດາກຸ່ມຂອງເຄື່ອງແມ່ຂ່າຍທີ່ບັນຫາໄດ້ຖືກສຶກສາ, ໃນສອງຕົວຕ້ານການນີ້ເພີ່ມຂຶ້ນໄວ, ສອງຊ້າຫຼາຍ, ແລະອີກສອງອັນມັນບໍ່ໄດ້ເພີ່ມຂຶ້ນເລີຍ. ການປຽບທຽບນະໂຍບາຍດ້ານຂອງຕົວຕ້ານການນີ້ກັບນະໂຍບາຍດ້ານຂອງຄວາມຜິດພາດ HTTP ໃນເຊີຟເວີ Java ໄດ້ເປີດເຜີຍຄວາມກ່ຽວຂ້ອງ. ນັ້ນແມ່ນ, ເຄື່ອງວັດແທກສາມາດຕິດຕາມໄດ້.

ການມີຕົວຊີ້ວັດທີ່ເຊື່ອຖືໄດ້ຂອງບັນຫາແມ່ນມີຄວາມສໍາຄັນຫຼາຍເພື່ອໃຫ້ທ່ານສາມາດກໍານົດໄດ້ຢ່າງຖືກຕ້ອງວ່າການກັບຄືນ Sysctl ຈະຊ່ວຍໄດ້, ເພາະວ່າຈາກເລື່ອງທີ່ຜ່ານມາພວກເຮົາຮູ້ວ່າມັນບໍ່ສາມາດເຂົ້າໃຈໄດ້ທັນທີຈາກຄໍາຮ້ອງສະຫມັກ. ຕົວຊີ້ວັດນີ້ຈະຊ່ວຍໃຫ້ພວກເຮົາກໍານົດບັນຫາທັງຫມົດໃນການຜະລິດກ່ອນທີ່ຜູ້ໃຊ້ຈະຄົ້ນພົບມັນ.
ຫຼັງຈາກ rolling ກັບຄືນໄປບ່ອນ Sysctl, ຄວາມຜິດພາດການຕິດຕາມຢຸດເຊົາ, ດັ່ງນັ້ນສາເຫດຂອງບັນຫາໄດ້ຖືກພິສູດ, ເຊັ່ນດຽວກັນກັບຄວາມຈິງທີ່ວ່າ rollback ຊ່ວຍ.

ພວກເຮົາມ້ວນຄືນການຕັ້ງຄ່າການແບ່ງສ່ວນໃນເຊີບເວີອື່ນ, ບ່ອນທີ່ການຕິດຕາມໃຫມ່ເຂົ້າມາ, ແລະບາງບ່ອນພວກເຮົາຈັດສັນຫນ່ວຍຄວາມຈໍາສໍາລັບ fragments ຫຼາຍກວ່າເດີມ (ນີ້ແມ່ນສະຖິຕິ UDP, ການສູນເສຍບາງສ່ວນທີ່ບໍ່ສັງເກດເຫັນກັບພື້ນຫລັງທົ່ວໄປ) .

ຄໍາຖາມທີ່ສໍາຄັນທີ່ສຸດ

ເປັນຫຍັງແພັກເກັດຈຶ່ງຖືກແຍກຢູ່ໃນຕົວດຸ່ນດ່ຽງ L3 ຂອງພວກເຮົາ? ສ່ວນໃຫຍ່ຂອງແພັກເກັດທີ່ມາຮອດຈາກຜູ້ໃຊ້ໄປຫາຜູ້ດຸ່ນດ່ຽງແມ່ນ SYN ແລະ ACK. ຂະຫນາດຂອງຊຸດເຫຼົ່ານີ້ແມ່ນຂະຫນາດນ້ອຍ. ແຕ່ເນື່ອງຈາກສ່ວນແບ່ງຂອງແພັກເກັດດັ່ງກ່າວແມ່ນມີຂະຫນາດໃຫຍ່ຫຼາຍ, ຕໍ່ກັບພື້ນຫລັງຂອງພວກເຂົາພວກເຮົາບໍ່ໄດ້ສັງເກດເຫັນການມີຊອງຂະຫນາດໃຫຍ່ທີ່ເລີ່ມແຕກຫັກ.

ເຫດຜົນແມ່ນສະຄຣິບການຕັ້ງຄ່າທີ່ແຕກຫັກ advmss ໃນເຊີບເວີທີ່ມີການໂຕ້ຕອບ Vlan (ມີເຄື່ອງແມ່ຂ່າຍຈໍານວນຫນ້ອຍທີ່ມີການຈະລາຈອນ tagged ໃນການຜະລິດໃນເວລານັ້ນ). Advmss ອະນຸຍາດໃຫ້ພວກເຮົາຖ່າຍທອດຂໍ້ມູນໃຫ້ແກ່ລູກຄ້າວ່າແພັກເກັດໃນທິດທາງຂອງພວກເຮົາຄວນຈະມີຂະຫນາດຂະຫນາດນ້ອຍກວ່າເພື່ອວ່າຫຼັງຈາກຕິດຫົວອຸໂມງກັບພວກມັນພວກເຂົາບໍ່ຈໍາເປັນຕ້ອງຖືກແຍກ.

ເປັນຫຍັງ Sysctl rollback ບໍ່ຊ່ວຍ, ແຕ່ reboot ໄດ້? Rolling back Sysctl ໄດ້ປ່ຽນຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ມີຢູ່ສໍາລັບການລວມແພັກເກັດ. ໃນຂະນະດຽວກັນ, ປາກົດຂື້ນວ່າຄວາມເປັນຈິງຂອງຄວາມຊົງຈໍາ overflow ສໍາລັບ fragments ນໍາໄປສູ່ການຊ້າລົງຂອງການເຊື່ອມຕໍ່, ເຊິ່ງເຮັດໃຫ້ fragments ຖືກຊັກຊ້າເປັນເວລາດົນນານໃນແຖວ. ນັ້ນແມ່ນ, ຂະບວນການໄດ້ເຂົ້າໄປໃນຮອບວຽນ.
reboot ໄດ້ລຶບລ້າງຄວາມຊົງຈໍາແລະທຸກສິ່ງທຸກຢ່າງກັບຄືນສູ່ຄໍາສັ່ງ.

ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໂດຍບໍ່ມີການແກ້ໄຂ? ແມ່ນແລ້ວ, ແຕ່ມີຄວາມສ່ຽງສູງທີ່ຈະປ່ອຍໃຫ້ຜູ້ໃຊ້ບໍ່ມີບໍລິການໃນກໍລະນີຂອງການໂຈມຕີ. ແນ່ນອນ, ການນໍາໃຊ້ Workaround ເຮັດໃຫ້ເກີດບັນຫາຕ່າງໆ, ລວມທັງການຊ້າລົງຂອງການບໍລິການຫນຶ່ງສໍາລັບຜູ້ໃຊ້, ແຕ່ຢ່າງໃດກໍ່ຕາມພວກເຮົາເຊື່ອວ່າການດໍາເນີນການແມ່ນຖືກຕ້ອງ.

ຂອບໃຈຫຼາຍໆກັບ Andrey Timofeev (Atimofeev) ສໍາລັບການຊ່ວຍເຫຼືອໃນການດໍາເນີນການສືບສວນ, ເຊັ່ນດຽວກັນກັບ Alexey Krenev (ອຸປະກອນx) - ສໍາລັບການເຮັດວຽກຂອງ Titanic ການປັບປຸງ Centos ແລະ kernels ໃນເຄື່ອງແມ່ຂ່າຍ. ຂະບວນການທີ່ໃນກໍລະນີນີ້ຕ້ອງໄດ້ຮັບການເລີ່ມຕົ້ນຈາກຈຸດເລີ່ມຕົ້ນຫຼາຍຄັ້ງ, ນັ້ນແມ່ນເຫດຜົນທີ່ມັນລາກມາເປັນເວລາຫຼາຍເດືອນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com