ກົງສຸນ + iptables = :3

ໃນປີ 2010 ບໍລິສັດ Wargaming ມີ 50 ເຄື່ອງແມ່ຂ່າຍແລະຮູບແບບເຄືອຂ່າຍງ່າຍດາຍ: backend, frontend ແລະ firewall. ຈໍານວນຂອງເຄື່ອງແມ່ຂ່າຍເພີ່ມຂຶ້ນ, ຮູບແບບໄດ້ກາຍເປັນສະລັບສັບຊ້ອນຫຼາຍ: staging, ແຍກ VLANs ກັບ ACLs, ຫຼັງຈາກນັ້ນ VPNs ກັບ VRFs, VLANs ກັບ ACLs ສຸດ L2, VRFs ກັບ ACLs ໃນ L3. ຫົວແມ່ນ spin? ມັນຈະມ່ວນຫຼາຍຕໍ່ມາ.

ເມື່ອມີ 16 ເຊີບເວີ, ມັນກໍ່ເປັນໄປບໍ່ໄດ້ທີ່ຈະເຮັດວຽກໂດຍບໍ່ມີນໍ້າຕາດ້ວຍພາກສ່ວນທີ່ຫຼາກຫຼາຍ. ດັ່ງນັ້ນພວກເຮົາໄດ້ມາເຖິງການແກ້ໄຂອື່ນ. ພວກເຮົາໄດ້ເອົາ Netfilter stack, ເພີ່ມ Consul ໃສ່ມັນເປັນແຫຼ່ງຂໍ້ມູນ, ແລະພວກເຮົາໄດ້ຮັບ Firewall ທີ່ແຈກຢາຍໄວ. ພວກເຂົາເຈົ້າໄດ້ທົດແທນ ACLs ໃນ routers ແລະນໍາໃຊ້ພວກມັນເປັນໄຟວໍພາຍນອກແລະພາຍໃນ. ເພື່ອຈັດການເຄື່ອງມືແບບເຄື່ອນໄຫວ, ພວກເຮົາໄດ້ພັດທະນາລະບົບ BEFW, ເຊິ່ງໄດ້ຖືກນໍາໃຊ້ຢູ່ທົ່ວທຸກແຫ່ງ: ຈາກການຄຸ້ມຄອງການເຂົ້າເຖິງຂອງຜູ້ໃຊ້ກັບເຄືອຂ່າຍຜະລິດຕະພັນເພື່ອແຍກສ່ວນເຄືອຂ່າຍຈາກກັນແລະກັນ.

ລາວຈະບອກເຈົ້າວ່າມັນເຮັດວຽກແນວໃດ ແລະເປັນຫຍັງເຈົ້າຈຶ່ງຄວນພິຈາລະນາເບິ່ງລະບົບນີ້ໃຫ້ລະອຽດ. Ivan Agarkov (anmuor) ເປັນຫົວຫນ້າກຸ່ມຄວາມປອດໄພພື້ນຖານໂຄງລ່າງຂອງພະແນກບໍາລຸງຮັກສາທີ່ສູນພັດທະນາ Minsk ຂອງບໍລິສັດ. Ivan ເປັນແຟນ SELinux, ຮັກ Perl, ແລະຂຽນລະຫັດ. ໃນຖານະເປັນຫົວຫນ້າກຸ່ມຄວາມປອດໄພຂໍ້ມູນຂ່າວສານ, ລາວເຮັດວຽກເປັນປົກກະຕິກັບບັນທຶກ, ການສໍາຮອງຂໍ້ມູນແລະ R&D ເພື່ອປົກປ້ອງ Wargaming ຈາກແຮກເກີແລະຮັບປະກັນການດໍາເນີນງານຂອງເຄື່ອງແມ່ຂ່າຍເກມທັງຫມົດໃນບໍລິສັດ.

ພື້ນຫລັງປະຫວັດສາດ

ກ່ອນທີ່ຂ້ອຍຈະບອກເຈົ້າວ່າພວກເຮົາໄດ້ເຮັດມັນແນວໃດ, ຂ້ອຍຈະບອກເຈົ້າວ່າພວກເຮົາມາບ່ອນນີ້ໃນຕອນທໍາອິດແລະເປັນຫຍັງມັນຈຶ່ງຕ້ອງການ. ເພື່ອເຮັດສິ່ງນີ້, ໃຫ້ກັບຄືນໄປບ່ອນ 9 ປີ: 2010, World of Tanks ພຽງແຕ່ປາກົດ. Wargaming ມີປະມານ 50 ເຊີບເວີ.

ຕາຕະລາງການຂະຫຍາຍຕົວຂອງເຄື່ອງແມ່ຂ່າຍຂອງບໍລິສັດ.

ພວກເຮົາມີຮູບແບບເຄືອຂ່າຍ. ສໍາລັບເວລານັ້ນມັນແມ່ນດີທີ່ສຸດ.

ຮູບແບບເຄືອຂ່າຍໃນປີ 2010.

ມີຄົນບໍ່ດີຢູ່ທາງຫນ້າທີ່ຕ້ອງການທໍາລາຍພວກເຮົາ, ແຕ່ມັນມີໄຟວໍ. ບໍ່ມີ firewall ໃນ backend, ແຕ່ມີ 50 servers ຢູ່ທີ່ນັ້ນ, ພວກເຮົາຮູ້ຈັກພວກມັນທັງຫມົດ. ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກໄດ້ດີ.

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

ຮູບແບບເຄືອຂ່າຍໃນປີ 2014.

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

ໃນປີ 2016, ຈໍານວນເຄື່ອງແມ່ຂ່າຍໄດ້ບັນລຸ 8000. Wargaming ໄດ້ດູດເອົາສະຕູດິໂອອື່ນໆ, ແລະເຄືອຂ່າຍພັນທະມິດເພີ່ມເຕີມໄດ້ປາກົດ. ພວກເຂົາເບິ່ງຄືວ່າເປັນຂອງພວກເຮົາ, ແຕ່ບໍ່ແມ່ນຂ້ອນຂ້າງ: VLAN ມັກຈະບໍ່ເຮັດວຽກສໍາລັບຄູ່ຮ່ວມງານ, ທ່ານຕ້ອງໃຊ້ VPN ກັບ VRF, ການໂດດດ່ຽວກາຍເປັນຄວາມສັບສົນຫຼາຍ. ການປະສົມ insulation ACL ເພີ່ມຂຶ້ນ.

ຮູບແບບເຄືອຂ່າຍໃນປີ 2016.

ໃນຕົ້ນປີ 2018, ເຮືອຂອງເຄື່ອງຈັກໄດ້ເພີ່ມຂຶ້ນເຖິງ 16. ມີ 000 ພາກສ່ວນ, ແລະພວກເຮົາບໍ່ໄດ້ນັບສ່ວນທີ່ເຫຼືອ, ລວມທັງເຄື່ອງປິດທີ່ຂໍ້ມູນທາງດ້ານການເງິນໄດ້ຖືກເກັບຮັກສາໄວ້. ເຄືອຂ່າຍຕູ້ຄອນເທນເນີ (Kubernetes), DevOps, ເຄືອຂ່າຍຄລາວທີ່ເຊື່ອມຕໍ່ຜ່ານ VPN, ຕົວຢ່າງ, ຈາກ IVS, ໄດ້ປະກົດຂຶ້ນ. ມີກົດລະບຽບຫຼາຍ - ມັນເຈັບປວດ.

ຮູບແບບເຄືອຂ່າຍ ແລະວິທີການໂດດດ່ຽວໃນປີ 2018.

ສໍາລັບການໂດດດ່ຽວທີ່ພວກເຮົາໃຊ້: VLAN ກັບ ACL ໃນ L2, VRF ກັບ ACL ໃນ L3, VPN ແລະອື່ນໆອີກ. ຫຼາຍເກີນໄປ.

ບັນຫາ

ທຸກຄົນອາໄສຢູ່ກັບ ACL ແລະ VLAN. ແມ່ນຫຍັງຜິດ? ຄໍາຖາມນີ້ຈະຖືກຕອບໂດຍ Harold, ເຊື່ອງຄວາມເຈັບປວດ.

ມີບັນຫາຫຼາຍຢ່າງ, ແຕ່ມີຫ້າອັນໃຫຍ່ຫຼວງ.

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

ນີ້ແມ່ນສິ່ງທີ່ນັກວິສະວະກອນເຄືອຂ່າຍເບິ່ງຄືວ່າໃນປີ 2018 ເມື່ອລາວໄດ້ຍິນ: "ຕ້ອງການ ACL ຕື່ມອີກ."

ວິທີແກ້ໄຂ

ໃນຕອນຕົ້ນຂອງ 2018, ມັນໄດ້ຖືກຕັດສິນໃຈເຮັດບາງສິ່ງບາງຢ່າງກ່ຽວກັບມັນ.

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

ການ​ແກ້​ໄຂ​: ພວກ​ເຮົາ​ເອົາ​ປັດ​ໄຈ​ມະ​ນຸດ​ອອກ​ແລະ​ອັດ​ຕະ​ໂນ​ມັດ​ການ​ສະ​ຫນອງ​ການ​ເຂົ້າ​ເຖິງ​ສູງ​ສຸດ​.

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

ບໍ່ມີ Firewall ພາຍໃນພາກສ່ວນ. Firewall ພາຍໃນ segments ໄດ້ເລີ່ມຕົ້ນມາຫາພວກເຮົາໃນເວລາທີ່ການບໍລິການທີ່ແຕກຕ່າງກັນປາກົດຢູ່ໃນເຄືອຂ່າຍດຽວກັນ. ການແກ້ໄຂ: ໃຊ້ firewall ໃນລະດັບເຈົ້າພາບ - host-based firewalls . ເກືອບທຸກບ່ອນທີ່ພວກເຮົາມີ Linux, ແລະທຸກບ່ອນທີ່ພວກເຮົາມີ iptables, ນີ້ບໍ່ແມ່ນບັນຫາ.

ຄວາມຫຍຸ້ງຍາກກັບກົດລະບຽບການກວດສອບ. ການແກ້ໄຂ: ຮັກສາກົດລະບຽບທັງຫມົດຢູ່ໃນສະຖານທີ່ດຽວສໍາລັບການທົບທວນຄືນແລະການຄຸ້ມຄອງ, ດັ່ງນັ້ນພວກເຮົາສາມາດກວດສອບທຸກສິ່ງທຸກຢ່າງ.

ລະດັບການຄວບຄຸມພື້ນຖານໂຄງລ່າງຕ່ໍາ. ການ​ແກ້​ໄຂ​: ເອົາ​ບັນ​ຊີ​ຂອງ​ການ​ບໍ​ລິ​ການ​ທັງ​ຫມົດ​ແລະ​ການ​ເຂົ້າ​ເຖິງ​ລະ​ຫວ່າງ​ເຂົາ​ເຈົ້າ​.

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

ຫຼັງຈາກທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາເປີດຕົວ, ວິສະວະກອນເຄືອຂ່າຍໃນປີ 2019 ເລີ່ມເປັນແບບນີ້.

ກົງສຸນ

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

ພວກເຮົາຕັດສິນໃຈເຮັດສິ່ງນີ້ແນວໃດ?

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

Consul ບໍ່ແມ່ນ API ຫ່າງໄກສອກຫຼີກ, ມັນສາມາດດໍາເນີນການໃນທຸກ node ແລະຂຽນໃສ່ iptables. ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນມາພ້ອມກັບເຄື່ອງມືຄວບຄຸມອັດຕະໂນມັດທີ່ຈະເຮັດຄວາມສະອາດສິ່ງທີ່ບໍ່ຈໍາເປັນ, ແລະບັນຫາສ່ວນໃຫຍ່ຈະຖືກແກ້ໄຂ! ພວກ​ເຮົາ​ຈະ​ເຮັດ​ວຽກ​ທີ່​ເຫຼືອ​ທີ່​ພວກ​ເຮົາ​ໄປ.

ເປັນຫຍັງກົງສຸນ?

ໄດ້ພິສູດຕົວເອງໄດ້ດີ. ໃນປີ 2014-15, ພວກເຮົາໄດ້ໃຊ້ມັນເປັນ backend ສໍາລັບ Vault, ໃນທີ່ພວກເຮົາເກັບຮັກສາລະຫັດຜ່ານ.

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

ການເຊື່ອມຕໍ່ P2P ເລັ່ງການແຜ່ກະຈາຍຂອງການປ່ຽນແປງ. ດ້ວຍ P2P, ການປ່ຽນແປງທັງຫມົດມາໄວ, ບໍ່ຈໍາເປັນຕ້ອງລໍຖ້າຊົ່ວໂມງ.

API REST ສະດວກ. ພວກເຮົາຍັງໄດ້ພິຈາລະນາ Apache ZooKeeper, ແຕ່ມັນບໍ່ມີ REST API, ດັ່ງນັ້ນທ່ານຈະຕ້ອງຕິດຕັ້ງໄມ້ຄ້ອນ.

ເຮັດວຽກເປັນທັງ Key Vault (KV) ແລະ Directory (Service Discovery). ທ່ານສາມາດເກັບຮັກສາການບໍລິການ, ລາຍການ, ແລະສູນຂໍ້ມູນໃນເວລາດຽວກັນ. ນີ້ແມ່ນສະດວກບໍ່ພຽງແຕ່ສໍາລັບພວກເຮົາ, ແຕ່ຍັງສໍາລັບທີມງານໃກ້ຄຽງ, ເພາະວ່າໃນເວລາທີ່ການກໍ່ສ້າງບໍລິການທົ່ວໂລກ, ພວກເຮົາຄິດວ່າໃຫຍ່.

ຂຽນໃນ Go, ເຊິ່ງເປັນສ່ວນຫນຶ່ງຂອງ Wargaming stack. ພວກເຮົາຮັກພາສານີ້, ພວກເຮົາມີນັກພັດທະນາ Go ຫຼາຍຄົນ.

ລະບົບ ACL ທີ່ມີປະສິດທິພາບ. ໃນກົງສຸນ, ທ່ານສາມາດນໍາໃຊ້ ACLs ເພື່ອຄວບຄຸມຜູ້ທີ່ຂຽນສິ່ງທີ່. ພວກເຮົາຮັບປະກັນວ່າກົດລະບຽບຂອງ Firewall ຈະບໍ່ທັບຊ້ອນກັບສິ່ງອື່ນແລະພວກເຮົາຈະບໍ່ມີບັນຫາກັບເລື່ອງນີ້.

ແຕ່ກົງສຸນຍັງມີຂໍ້ບົກຜ່ອງຂອງມັນ.

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

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

ກົງສຸນເຮັດວຽກແນວໃດ

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

ລູກຄ້າເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍໃນຄໍາສັ່ງໃດກໍ່ຕາມ: ຕົວແທນດຽວກັນ, ພຽງແຕ່ມີທຸງ server = false.

ຫຼັງຈາກນີ້, ລູກຄ້າໄດ້ຮັບບັນຊີລາຍຊື່ຂອງການເຊື່ອມຕໍ່ P2P ແລະສ້າງການເຊື່ອມຕໍ່ລະຫວ່າງພວກເຂົາ.

ໃນລະດັບໂລກ, ພວກເຮົາເຊື່ອມຕໍ່ສູນຂໍ້ມູນຫຼາຍແຫ່ງ. ພວກເຂົາຍັງເຊື່ອມຕໍ່ P2P ແລະຕິດຕໍ່ສື່ສານ.

ເມື່ອພວກເຮົາຕ້ອງການດຶງຂໍ້ມູນຈາກສູນຂໍ້ມູນອື່ນ, ການຮ້ອງຂໍໄປຈາກເຄື່ອງແມ່ຂ່າຍໄປຫາເຄື່ອງແມ່ຂ່າຍ. ໂຄງການນີ້ເອີ້ນວ່າ ໂປໂຕຄອນ Serf. ອະນຸສັນຍາ Serf, ເຊັ່ນ Consul, ຖືກພັດທະນາໂດຍ HashiCorp.

ຂໍ້ເທັດຈິງທີ່ສໍາຄັນບາງຢ່າງກ່ຽວກັບກົງສຸນ

ກົງສຸນມີເອກະສານອະທິບາຍວິທີການເຮັດວຽກ. ຂ້ອຍຈະໃຫ້ຂໍ້ເທັດຈິງທີ່ເລືອກເທົ່ານັ້ນທີ່ມີມູນຄ່າຮູ້.

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

ທ່ານຕ້ອງການປັບຂະໜາດແນວນອນບໍ? ຂໍອະໄພ, ບໍ່.

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

ວິທີດຽວທີ່ຈະປັບຂະ ໜາດ ແມ່ນການເປີດໃຊ້ຮູບແບບ stale ໃນລູກຄ້າ.

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

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

ປະລໍາມະນູຂອງການດໍາເນີນງານບໍ່ໄດ້ຖືກຮັບປະກັນນອກການເຮັດທຸລະກໍາ. ຈົ່ງຈື່ໄວ້ວ່າເຈົ້າບໍ່ແມ່ນຜູ້ດຽວທີ່ສາມາດປ່ຽນແປງສິ່ງຕ່າງໆ. ຖ້າທ່ານຕ້ອງການມັນແຕກຕ່າງກັນ, ດໍາເນີນການເຮັດທຸລະກໍາດ້ວຍການລັອກ.

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

ACL ຍັງບໍ່ຮັບປະກັນການເຂົ້າເຖິງ (ໃນຫຼາຍໆກໍລະນີ). ACL ອາດຈະບໍ່ເຮັດວຽກເພາະວ່າມັນຖືກເກັບໄວ້ໃນສູນຂໍ້ມູນສະຫະພັນຫນຶ່ງ - ໃນສູນຂໍ້ມູນ ACL (Primary DC). ຖ້າ DC ບໍ່ຕອບທ່ານ, ACL ຈະບໍ່ເຮັດວຽກ.

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

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

ພວກເຮົາພົບບັນຫານີ້ ແລະຕ້ອງສ້າງພາກສ່ວນສະເພາະຂອງສູນຂໍ້ມູນຄືນໃໝ່ເພື່ອຫຼີກເວັ້ນມັນ.

ສະບັບທຸລະກິດຂອງ Consul Enterprise ບໍ່ມີບາງຂໍ້ເສຍຂ້າງເທິງ. ມັນ​ມີ​ຫນ້າ​ທີ່​ທີ່​ເປັນ​ປະ​ໂຫຍດ​ຫຼາຍ​: ການ​ເລືອກ​ເອົາ​ຜູ້​ລົງ​ຄະ​ແນນ​ສຽງ​, ການ​ແຜ່​ກະ​ຈາຍ​, ການ​ຂະ​ຫຍາຍ​. ມີພຽງແຕ່ຫນຶ່ງ "ແຕ່" - ລະບົບໃບອະນຸຍາດສໍາລັບລະບົບການແຈກຢາຍແມ່ນລາຄາແພງຫຼາຍ.

ຊີວິດການລະເມີດ: rm -rf /var/lib/consul - ການປິ່ນປົວສໍາລັບທຸກພະຍາດຂອງຕົວແທນ. ຖ້າບາງສິ່ງບາງຢ່າງໃຊ້ບໍ່ໄດ້ສໍາລັບທ່ານ, ພຽງແຕ່ລຶບຂໍ້ມູນຂອງທ່ານແລະດາວໂຫລດຂໍ້ມູນຈາກສໍາເນົາ. ສ່ວນຫຼາຍອາດຈະ, Consul ຈະເຮັດວຽກ.

BEFW

ຕອນນີ້ໃຫ້ເວົ້າກ່ຽວກັບສິ່ງທີ່ພວກເຮົາໄດ້ເພີ່ມໃສ່ກົງສຸນ.

BEFW ແມ່ນຕົວຫຍໍ້ຂອງ BackEndFຂ້ອຍ​ຈະ​ໄປWທັງໝົດ. ຂ້ອຍຕ້ອງຕັ້ງຊື່ຜະລິດຕະພັນບາງຢ່າງເມື່ອຂ້ອຍສ້າງບ່ອນເກັບມ້ຽນເພື່ອເອົາການທົດສອບຄັ້ງທໍາອິດເຂົ້າໄປໃນມັນ. ຊື່ນີ້ຍັງຄົງຢູ່.

ແມ່ແບບກົດລະບຽບ

ກົດລະບຽບຖືກຂຽນໄວ້ໃນ syntax iptables.

• -N BEFW
• -P INPUT ຫຼຸດລົງ
• -A input -m state—ລັດທີ່ກ່ຽວຂ້ອງ, ສ້າງຕັ້ງຂຶ້ນ -j ຍອມຮັບ
• -A INPUT -i lo -j ຍອມຮັບ
• -ການປ້ອນຂໍ້ມູນ -j BEFW

ທຸກສິ່ງທຸກຢ່າງເຂົ້າໄປໃນລະບົບຕ່ອງໂສ້ BEFW, ຍົກເວັ້ນ ESTABLISHED, RELATED ແລະ localhost. ແມ່ແບບສາມາດເປັນສິ່ງໃດກໍ່ຕາມ, ນີ້ແມ່ນພຽງແຕ່ຕົວຢ່າງ.

BEFW ມີປະໂຫຍດແນວໃດ?

ບໍລິການ

ພວກເຮົາມີບໍລິການ, ມັນສະເຫມີມີພອດ, node ທີ່ມັນແລ່ນ. ຈາກ node ຂອງພວກເຮົາ, ພວກເຮົາສາມາດສອບຖາມຕົວແທນໃນທ້ອງຖິ່ນແລະຊອກຫາວ່າພວກເຮົາມີການບໍລິການບາງປະເພດ. ນອກນັ້ນທ່ານຍັງສາມາດໃສ່ tags.

ການບໍລິການໃດໆທີ່ດໍາເນີນການແລະລົງທະບຽນກັບ Consul ກາຍເປັນກົດລະບຽບ iptables. ພວກເຮົາມີ SSH - open port 22. script Bash ແມ່ນງ່າຍດາຍ: curl ແລະ iptables, ບໍ່ມີຫຍັງອີກທີ່ຈໍາເປັນ.

ລູກຄ້າ

ວິທີການເປີດການເຂົ້າເຖິງບໍ່ໃຫ້ທຸກຄົນ, ແຕ່ເລືອກ? ເພີ່ມລາຍການ IP ໃສ່ບ່ອນເກັບມ້ຽນ KV ໂດຍຊື່ບໍລິການ.

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

ການເຂົ້າເຖິງ

ພວກເຮົາເຊື່ອມຕໍ່ການບໍລິການແລະລູກຄ້າ: ພວກເຮົາມີບໍລິການ, ການເກັບຮັກສາ KV ແມ່ນກຽມພ້ອມສໍາລັບແຕ່ລະຄົນ. ຕອນນີ້ພວກເຮົາໃຫ້ການເຂົ້າເຖິງບໍ່ແມ່ນທຸກຄົນ, ແຕ່ເລືອກ.

ກຸ່ມ

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

ໃຫ້ເຊື່ອມຕໍ່ກັນ: ຕອນນີ້ພວກເຮົາສາມາດເປີດ SSH ບໍ່ພຽງແຕ່ສໍາລັບ P2P, ແຕ່ສໍາລັບກຸ່ມທັງຫມົດຫຼືຫຼາຍກຸ່ມ. ໃນລັກສະນະດຽວກັນ, ມີ TTL - ທ່ານສາມາດເພີ່ມເຂົ້າໄປໃນກຸ່ມແລະເອົາອອກຈາກກຸ່ມຊົ່ວຄາວ.

ການເຊື່ອມໂຍງ

ບັນຫາຂອງພວກເຮົາແມ່ນປັດໃຈຂອງມະນຸດແລະອັດຕະໂນມັດ. ມາຮອດປະຈຸ, ພວກເຮົາໄດ້ແກ້ໄຂມັນດ້ວຍວິທີນີ້.

ພວກເຮົາເຮັດວຽກກັບ Puppet, ແລະໂອນທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບລະບົບ (ລະຫັດຄໍາຮ້ອງສະຫມັກ) ໃຫ້ພວກເຂົາ. Puppetdb (PostgreSQL ປົກກະຕິ) ເກັບຮັກສາບັນຊີລາຍຊື່ຂອງການບໍລິການທີ່ເຮັດວຽກຢູ່ທີ່ນັ້ນ, ພວກເຂົາສາມາດພົບໄດ້ໂດຍປະເພດຊັບພະຍາກອນ. ຢູ່ທີ່ນັ້ນເຈົ້າສາມາດຊອກຫາຜູ້ທີ່ກໍາລັງສະຫມັກຢູ່ບ່ອນໃດ. ພວກ​ເຮົາ​ຍັງ​ມີ​ການ​ຮ້ອງ​ຂໍ​ດຶງ​ແລະ​ການ​ລວມ​ລະ​ບົບ​ການ​ຮ້ອງ​ຂໍ​ສໍາ​ລັບ​ການ​ນີ້​.

ພວກເຮົາຂຽນ befw-sync, ການແກ້ໄຂງ່າຍໆທີ່ຊ່ວຍໂອນຂໍ້ມູນ. ຫນ້າທໍາອິດ, sync cookies ແມ່ນເຂົ້າເຖິງໂດຍ puppetdb. HTTP API ຖືກຕັ້ງຄ່າຢູ່ທີ່ນັ້ນ: ພວກເຮົາຮ້ອງຂໍໃຫ້ມີການບໍລິການໃດແດ່ທີ່ພວກເຮົາມີ, ສິ່ງທີ່ຕ້ອງເຮັດ. ຫຼັງ​ຈາກ​ນັ້ນ​ເຂົາ​ເຈົ້າ​ເຮັດ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ກັບ​ກົງ​ສຸນ​.

ມີການເຊື່ອມໂຍງບໍ? ແມ່ນແລ້ວ: ພວກເຂົາຂຽນກົດລະບຽບແລະອະນຸຍາດໃຫ້ Pull Requests ໄດ້ຮັບການຍອມຮັບ. ທ່ານຕ້ອງການພອດທີ່ແນ່ນອນຫຼືເພີ່ມໂຮດກັບບາງກຸ່ມບໍ? ດຶງຄໍາຮ້ອງຂໍ, ທົບທວນ - ບໍ່ມີ "ຊອກຫາ 200 ACLs ອື່ນໆແລະພະຍາຍາມເຮັດບາງສິ່ງບາງຢ່າງກ່ຽວກັບມັນ."

ການເພີ່ມປະສິດທິພາບ

Pinging localhost ທີ່ມີລະບົບຕ່ອງໂສ້ກົດລະບຽບຫວ່າງເປົ່າໃຊ້ເວລາ 0,075 ms.

ມາເພີ່ມ 10 ທີ່ຢູ່ iptables ໃຫ້ກັບລະບົບຕ່ອງໂສ້ນີ້. ດັ່ງນັ້ນ, ping ຈະເພີ່ມຂຶ້ນ 000 ເທົ່າ: iptables ແມ່ນເສັ້ນຢ່າງສົມບູນ, ການປຸງແຕ່ງແຕ່ລະທີ່ຢູ່ໃຊ້ເວລາບາງເວລາ.

ສໍາລັບ firewall ທີ່ພວກເຮົາເຄື່ອນຍ້າຍ ACL ຫຼາຍພັນຄົນ, ພວກເຮົາມີກົດລະບຽບຫຼາຍ, ແລະນີ້ແນະນໍາ latency. ນີ້ແມ່ນບໍ່ດີສໍາລັບໂປໂຕຄອນການຫຼິ້ນເກມ.

ແຕ່ຖ້າພວກເຮົາໃສ່ 10 ທີ່ຢູ່ ipset ping ຍັງຈະຫຼຸດລົງ.

ຈຸດແມ່ນວ່າ "O" (ຄວາມສັບສົນຂອງສູດການຄິດໄລ່) ສໍາລັບ ipset ແມ່ນສະເຫມີເທົ່າກັບ 1, ບໍ່ວ່າຈະມີກົດລະບຽບຫຼາຍປານໃດ. ແທ້ຈິງແລ້ວ, ມີຂໍ້ຈໍາກັດ - ບໍ່ສາມາດມີຫຼາຍກ່ວາ 65535 ກົດລະບຽບ. ສໍາລັບໃນປັດຈຸບັນພວກເຮົາອາໄສຢູ່ກັບນີ້: ທ່ານສາມາດສົມທົບພວກມັນ, ຂະຫຍາຍພວກມັນ, ສ້າງສອງ ipsets ໃນຫນຶ່ງ.

ການເກັບຮັກສາ

ການສືບຕໍ່ຢ່າງມີເຫດຜົນຂອງຂະບວນການ iteration ແມ່ນການເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບລູກຄ້າສໍາລັບການບໍລິການໃນ ipset.

ໃນປັດຈຸບັນພວກເຮົາມີ SSH ດຽວກັນ, ແລະພວກເຮົາບໍ່ໄດ້ຂຽນ 100 IPs ໃນເວລາດຽວກັນ, ແຕ່ກໍານົດຊື່ຂອງ ipset ທີ່ພວກເຮົາຕ້ອງການສື່ສານ, ແລະກົດລະບຽບຕໍ່ໄປນີ້. DROP. ມັນສາມາດຖືກປ່ຽນເປັນກົດລະບຽບດຽວ "ໃຜບໍ່ຢູ່ທີ່ນີ້, ລຸດລົງ", ແຕ່ມັນຈະແຈ້ງກວ່າ.

ໃນປັດຈຸບັນພວກເຮົາມີກົດລະບຽບແລະຊຸດ. ວຽກງານຕົ້ນຕໍແມ່ນເພື່ອເຮັດໃຫ້ຊຸດກ່ອນທີ່ຈະຂຽນກົດລະບຽບ, ເພາະວ່າຖ້າບໍ່ດັ່ງນັ້ນ iptables ຈະບໍ່ຂຽນກົດລະບຽບ.

ໂຄງການທົ່ວໄປ

ໃນ​ຮູບ​ແບບ​ຂອງ​ແຜນ​ວາດ​, ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເວົ້າ​ວ່າ​ຄ້າຍ​ຄື​ນີ້​.

ພວກເຮົາຫມັ້ນສັນຍາກັບ Puppet, ທຸກສິ່ງທຸກຢ່າງຖືກສົ່ງໄປຫາເຈົ້າພາບ, ການບໍລິການຢູ່ທີ່ນີ້, ipset ຢູ່ທີ່ນັ້ນ, ແລະຜູ້ທີ່ບໍ່ໄດ້ລົງທະບຽນຢູ່ທີ່ນັ້ນແມ່ນບໍ່ໄດ້ຮັບອະນຸຍາດ.

ອະ​ນຸ​ຍາດ​ໃຫ້​ປະ​ຕິ​ເສດ

ເພື່ອຊ່ວຍປະຢັດໂລກຢ່າງໄວວາຫຼືປິດການທໍາງານຜູ້ໃດຜູ້ຫນຶ່ງຢ່າງໄວວາ, ໃນຕອນເລີ່ມຕົ້ນຂອງຕ່ອງໂສ້ທັງຫມົດພວກເຮົາໄດ້ສ້າງສອງ ipsets: rules_allow и rules_deny. ມັນເຮັດວຽກແນວໃດ?

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

ພວກເຮົາສົ່ງໃຫ້ກົງສຸນ, ລໍຖ້າ 2,5 ວິນາທີ, ແລະມັນສໍາເລັດ. ນັບຕັ້ງແຕ່ Consul ແຈກຢາຍຢ່າງໄວວາໂດຍຜ່ານ P2P, ມັນເຮັດວຽກຢູ່ທົ່ວທຸກແຫ່ງ, ໃນທຸກພາກສ່ວນຂອງໂລກ.

ເມື່ອຂ້ອຍຢຸດ WOT ຢ່າງສົມບູນຍ້ອນຄວາມຜິດພາດກັບໄຟວໍ. rules_allow - ນີ້ແມ່ນປະກັນໄພຂອງພວກເຮົາຕໍ່ກັບກໍລະນີດັ່ງກ່າວ. ຖ້າພວກເຮົາເຮັດຜິດພາດຢູ່ບ່ອນໃດບ່ອນໜຶ່ງກັບໄຟວໍ, ບາງອັນຖືກບລັອກຢູ່ບ່ອນໃດບ່ອນໜຶ່ງ, ພວກເຮົາສາມາດສົ່ງເງື່ອນໄຂໄດ້ສະເໝີ 0.0/0ເພື່ອເອົາທຸກສິ່ງທຸກຢ່າງຂຶ້ນຢ່າງໄວວາ. ຕໍ່ມາພວກເຮົາຈະແກ້ໄຂທຸກຢ່າງດ້ວຍມື.

ຊຸດອື່ນໆ

ທ່ານສາມາດເພີ່ມຊຸດອື່ນໆໃນຊ່ອງ $IPSETS$.

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

ຜູ້ໃຊ້

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

ພວກເຮົາໄດ້ເຮັດຫຍັງ? ພວກເຮົາຕິດຢູ່ໃນເວລານີ້ພວກເຮົາໄດ້ຮັບທີ່ຢູ່. ໂດຍປົກກະຕິແລ້ວນີ້ແມ່ນ dot1x, Wi-Fi ຫຼື VPN - ທຸກຢ່າງຜ່ານ RADIUS. ສໍາລັບຜູ້ໃຊ້ແຕ່ລະຄົນ, ພວກເຮົາສ້າງກຸ່ມໂດຍຊື່ຜູ້ໃຊ້ແລະວາງ IP ໃນມັນດ້ວຍ TTL ທີ່ເທົ່າກັບ dhcp.lease ຂອງມັນ - ທັນທີທີ່ມັນຫມົດອາຍຸ, ກົດລະບຽບຈະຫາຍໄປ.

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

Insulation

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

ໂຄງ​ການ​ນີ້​ເຮັດ​ວຽກ​ຢ່າງ​ວ່ອງ​ໄວ​ແລະ​ງ່າຍ​ດາຍ​: ພວກ​ເຮົາ​ເອົາ ACLs ທັງ​ຫມົດ​ຈາກ​ເຄື່ອງ​ແມ່​ຂ່າຍ​, unload the hardware​, ແລະ​ຫຼຸດ​ຜ່ອນ​ຈໍາ​ນວນ​ຂອງ VLANs ໂດດ​ດ່ຽວ​.

ການຄວບຄຸມຄວາມສົມບູນ

ກ່ອນຫນ້ານີ້, ພວກເຮົາມີຕົວກະຕຸ້ນພິເສດທີ່ລາຍງານເມື່ອມີຄົນປ່ຽນກົດລະບຽບໄຟວໍດ້ວຍຕົນເອງ. ຂ້ອຍກໍາລັງຂຽນ linter ຂະຫນາດໃຫຍ່ສໍາລັບການກວດສອບກົດລະບຽບຂອງ firewall, ມັນເປັນການຍາກ. ດຽວນີ້ຄວາມຊື່ສັດຖືກຄວບຄຸມໂດຍ BEFW. ພະອົງ​ຮັບປະກັນ​ຢ່າງ​ກະຕືລືລົ້ນ​ວ່າ​ກົດ​ເກນ​ທີ່​ພະອົງ​ເຮັດ​ບໍ່​ປ່ຽນ​ແປງ. ຖ້າໃຜຜູ້ຫນຶ່ງປ່ຽນກົດລະບຽບຂອງ Firewall, ມັນຈະປ່ຽນທຸກສິ່ງທຸກຢ່າງກັບຄືນ. “ຂ້ອຍຕັ້ງຕົວແທນໄວເພື່ອໃຫ້ຂ້ອຍສາມາດເຮັດວຽກຈາກບ້ານໄດ້”—ບໍ່ມີທາງເລືອກແບບນີ້ອີກແລ້ວ.

BEFW ຄວບຄຸມ ipset ຈາກການບໍລິການແລະລາຍຊື່ໃນ befw.conf, ກົດລະບຽບຂອງການບໍລິການໃນລະບົບຕ່ອງໂສ້ BEFW. ແຕ່ມັນບໍ່ໄດ້ຕິດຕາມລະບົບຕ່ອງໂສ້ແລະກົດລະບຽບອື່ນໆແລະ ipsets ອື່ນໆ.

ການປ້ອງກັນການຂັດຂ້ອງ

BEFW ສະເຫມີເກັບຮັກສາລັດທີ່ດີທີ່ຮູ້ຈັກສຸດທ້າຍໂດຍກົງໃນໂຄງສ້າງຖານສອງ state.bin. ຖ້າມີບາງຢ່າງຜິດພາດ, ມັນຈະກັບຄືນໄປຫາ state.bin ນີ້ສະເໝີ.

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

ໃນສະຖານະການທີ່ສໍາຄັນ, ນີ້ແມ່ນການຮັບປະກັນວ່າພວກເຮົາຈະປະໄວ້ກັບ firewall ທີ່ເຮັດວຽກ. ພວກເຮົາເປີດເຄືອຂ່າຍສີຂີ້ເຖົ່າທັງຫມົດໃນຄວາມຫວັງທີ່ admin ຈະມາແລະແກ້ໄຂມັນ. ມື້ຫນຶ່ງຂ້ອຍຈະເອົາສິ່ງນີ້ໄວ້ໃນການຕັ້ງຄ່າ, ແຕ່ຕອນນີ້ພວກເຮົາມີພຽງແຕ່ສາມເຄືອຂ່າຍສີຂີ້ເຖົ່າ: 10/8, 172/12 ແລະ 192.168/16. ພາຍໃນກົງສຸນຂອງພວກເຮົາ, ນີ້ແມ່ນລັກສະນະທີ່ສໍາຄັນທີ່ຊ່ວຍໃຫ້ພວກເຮົາພັດທະນາຕື່ມອີກ.

ການສາທິດ: ໃນລະຫວ່າງການລາຍງານ, Ivan ສະແດງໃຫ້ເຫັນຮູບແບບຕົວຢ່າງຂອງ BEFW. ມັນງ່າຍທີ່ຈະເບິ່ງການສາທິດ видео. ມີລະຫັດແຫຼ່ງຕົວຢ່າງ ໃນ GitHub.

ຜິດພະລາດ

ຂ້ອຍຈະບອກເຈົ້າກ່ຽວກັບແມງໄມ້ທີ່ພວກເຮົາພົບ.

ipset ເພີ່ມຊຸດ 0.0.0.0/0. ຈະເກີດຫຍັງຂຶ້ນຖ້າທ່ານເພີ່ມ 0.0.0.0/0 ໃສ່ ipset? IP ທັງຫມົດຈະຖືກເພີ່ມບໍ? ອິນເຕີເນັດຈະສາມາດໃຊ້ໄດ້ບໍ?

ບໍ່, ພວກເຮົາຈະໄດ້ຮັບຂໍ້ບົກພ່ອງທີ່ເຮັດໃຫ້ພວກເຮົາເສຍເວລາສອງຊົ່ວໂມງ. ຍິ່ງໄປກວ່ານັ້ນ, ແມງໄມ້ບໍ່ໄດ້ເຮັດວຽກຕັ້ງແຕ່ປີ 2016, ມັນຕັ້ງຢູ່ໃນ RedHat Bugzilla ພາຍໃຕ້ເລກ #1297092, ແລະພວກເຮົາພົບເຫັນມັນໂດຍບັງເອີນ - ຈາກບົດລາຍງານຂອງຜູ້ພັດທະນາ.

ໃນປັດຈຸບັນມັນເປັນກົດລະບຽບທີ່ເຂັ້ມງວດຢູ່ BEFW ວ່າ 0.0.0.0/0 ປ່ຽນເປັນສອງທີ່ຢູ່: 0.0.0.0/1 и 128.0.0.0/1.

ipset ຟື້ນຟູຊຸດ <ໄຟລ໌. ipset ເຮັດຫຍັງແດ່ເມື່ອທ່ານບອກມັນ restore? ທ່ານຄິດວ່າມັນເຮັດວຽກຄືກັນກັບ iptables ບໍ? ມັນຈະຟື້ນຕົວຂໍ້ມູນບໍ?

ບໍ່ມີຫຍັງຄືກັນ - ມັນປະສົມປະສານ, ແລະທີ່ຢູ່ເກົ່າບໍ່ໄດ້ໄປບ່ອນໃດກໍ່ຕາມ, ທ່ານບໍ່ປິດກັ້ນການເຂົ້າເຖິງ.

ພວກ​ເຮົາ​ໄດ້​ພົບ​ເຫັນ bug ໃນ​ເວ​ລາ​ທີ່​ການ​ທົດ​ສອບ​ການ​ໂດດ​ດ່ຽວ​. ໃນປັດຈຸບັນມີລະບົບສະລັບສັບຊ້ອນຫຼາຍ - ແທນທີ່ຈະ restore ໄດ້ຈັດຂຶ້ນ create tempຫຼັງຈາກນັ້ນ, restore flush temp и restore temp. ໃນຕອນທ້າຍຂອງ swap: ສໍາລັບປະລໍາມະນູ, ເພາະວ່າຖ້າທ່ານເຮັດມັນຄັ້ງທໍາອິດ flush ແລະໃນເວລານີ້ບາງຊອງມາຮອດ, ມັນຈະຖືກຍົກເລີກແລະບາງສິ່ງບາງຢ່າງຈະຜິດພາດ. ດັ່ງນັ້ນມີ magic ສີດໍາເລັກນ້ອຍຢູ່ທີ່ນັ້ນ.

consul kv get -datacenter=ອື່ນໆ. ດັ່ງທີ່ຂ້ອຍເວົ້າ, ພວກເຮົາຄິດວ່າພວກເຮົາຂໍຂໍ້ມູນບາງຢ່າງ, ແຕ່ພວກເຮົາຈະໄດ້ຮັບຂໍ້ມູນຫຼືຂໍ້ຜິດພາດ. ພວກເຮົາສາມາດເຮັດສິ່ງນີ້ໃນທ້ອງຖິ່ນໂດຍຜ່ານ Consul, ແຕ່ໃນກໍລະນີນີ້ທັງສອງຈະ freeze.

ລູກຄ້າ Consul ທ້ອງຖິ່ນແມ່ນ wrapper ຜ່ານ HTTP API. ແຕ່ມັນພຽງແຕ່ hangs ແລະບໍ່ຕອບສະຫນອງຕໍ່ Ctrl+C, ຫຼື Ctrl+Z, ຫຼືຫຍັງ, ເທົ່ານັ້ນ kill -9 ໃນ console ຕໍ່ໄປ. ພວກເຮົາພົບສິ່ງນີ້ໃນເວລາທີ່ພວກເຮົາກໍາລັງສ້າງກຸ່ມຂະຫນາດໃຫຍ່. ແຕ່ພວກເຮົາຍັງບໍ່ມີການແກ້ໄຂເທື່ອ; ພວກເຮົາກະກຽມແກ້ໄຂຂໍ້ຜິດພາດນີ້ຢູ່ໃນກົງສຸນ.

ຜູ້ນຳກົງສຸນບໍ່ຕອບສະໜອງ. ນາຍຂອງພວກເຮົາຢູ່ໃນສູນຂໍ້ມູນບໍ່ໄດ້ຕອບສະຫນອງ, ພວກເຮົາຄິດວ່າ: "ບາງທີວິທີການເລືອກໃຫມ່ຈະເຮັດວຽກໃນປັດຈຸບັນ?"

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

ພວກເຮົາຈະຈັດການກັບສິ່ງນີ້ແນວໃດ? service consul restart ໃນ cron ທຸກໆຊົ່ວໂມງ. ຖ້າທ່ານມີ 50 ເຄື່ອງແມ່ຂ່າຍ, ບໍ່ມີເລື່ອງໃຫຍ່. ເມື່ອມີ 16 ຂອງພວກເຂົາ, ທ່ານຈະເຂົ້າໃຈວ່າມັນເຮັດວຽກແນວໃດ.

ສະຫລຸບ

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບປະໂຫຍດດັ່ງຕໍ່ໄປນີ້:

• ການຄຸ້ມຄອງ 100% ຂອງເຄື່ອງ Linux ທັງໝົດ.
• ຄວາມໄວ.
• ອັດຕະໂນມັດ.
• ພວກເຮົາປົດປ່ອຍຮາດແວ ແລະວິສະວະກອນເຄືອຂ່າຍຈາກການເປັນຂ້າທາດ.
• ຄວາມເປັນໄປໄດ້ຂອງການປະສົມປະສານໄດ້ປະກົດວ່າເກືອບບໍ່ຈໍາກັດ: ເຖິງແມ່ນວ່າກັບ Kubernetes, ເຖິງແມ່ນວ່າມີ Ansible, ເຖິງແມ່ນວ່າມີ Python.

Минусы: Consul, ທີ່​ພວກ​ເຮົາ​ໃນ​ປັດ​ຈຸ​ບັນ​ມີ​ການ​ດໍາ​ລົງ​ຊີ​ວິດ, ແລະ​ຄ່າ​ໃຊ້​ຈ່າຍ​ສູງ​ຫຼາຍ​ຂອງ​ຄວາມ​ຜິດ​ພາດ. ຕົວຢ່າງ, ເມື່ອເວລາ 6 ໂມງແລງ (ເວລາທໍາອິດໃນລັດເຊຍ) ຂ້ອຍກໍາລັງແກ້ໄຂບາງສິ່ງບາງຢ່າງໃນບັນຊີລາຍຊື່ຂອງເຄືອຂ່າຍ. ພວກເຮົາພຽງແຕ່ກໍ່ສ້າງ insulation ຢູ່ BEFW ໃນເວລານັ້ນ. ຂ້ອຍເຮັດຜິດພາດຢູ່ບ່ອນໃດບ່ອນໜຶ່ງ, ເບິ່ງຄືວ່າຂ້ອຍຊີ້ໜ້າກາກຜິດ, ແຕ່ທຸກຢ່າງຕົກໃນສອງວິນາທີ. ແສງຕິດຕາມກວດກາ, ພະນັກງານສະຫນັບສະຫນູນກໍາລັງແລ່ນມາ: "ພວກເຮົາມີທຸກສິ່ງທຸກຢ່າງ!" ຫົວຫນ້າພະແນກຫັນເປັນສີຂີ້ເຖົ່າໃນເວລາທີ່ລາວອະທິບາຍໃຫ້ທຸລະກິດວ່າເປັນຫຍັງນີ້ເກີດຂຶ້ນ.

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

ຄ່າໃຊ້ຈ່າຍ ຂ້ອຍຂຽນລະຫັດເປັນເວລາ 400 ຊົ່ວໂມງຄົນດຽວ. ທີມງານຂອງຂ້ອຍ 4 ຄົນໃຊ້ເວລາ 10 ຊົ່ວໂມງຕໍ່ເດືອນເພື່ອສະຫນັບສະຫນູນທຸກໆຄົນ. ເມື່ອປຽບທຽບກັບລາຄາຂອງ firewall ຮຸ່ນໃຫມ່, ມັນບໍ່ເສຍຄ່າ.

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

ແຜນການທັນທີທັນໃດ: ການເຊື່ອມໂຍງກັບ Fail2ban, ດ້ວຍການຕິດຕາມກວດກາ, ດ້ວຍ nftables, ອາດຈະເປັນການແຈກຢາຍອື່ນໆ, metrics, ການຕິດຕາມແບບພິເສດ, ການເພີ່ມປະສິດທິພາບ. ການຊ່ວຍເຫຼືອ Kubernetes ແມ່ນຢູ່ບ່ອນໃດບ່ອນໜຶ່ງໃນແຜນການ, ເພາະວ່າຕອນນີ້ພວກເຮົາມີຫຼາຍກຸ່ມ ແລະ ຄວາມປາຖະຫນາ.

ເພີ່ມເຕີມຈາກແຜນການ:

• ຄົ້ນຫາຄວາມຜິດປົກກະຕິໃນການຈະລາຈອນ;
• ການຄຸ້ມຄອງແຜນທີ່ເຄືອຂ່າຍ;
• Kubernetes ສະຫນັບສະຫນູນ;
• ການຫຸ້ມຫໍ່ປະກອບສໍາລັບລະບົບທັງຫມົດ;
• Web-UI.

ພວກເຮົາກໍາລັງເຮັດວຽກຢ່າງຕໍ່ເນື່ອງກ່ຽວກັບການຂະຫຍາຍການຕັ້ງຄ່າ, ເພີ່ມທະວີການວັດແທກແລະການເພີ່ມປະສິດທິພາບ.

ເຂົ້າຮ່ວມໂຄງການ. ໂຄງການດັ່ງກ່າວໄດ້ຫັນອອກມາເປັນຄວາມເຢັນ, ແຕ່ຫນ້າເສຍດາຍ, ມັນຍັງເປັນໂຄງການຫນຶ່ງຄົນ. ມາ GitHub ແລະພະຍາຍາມເຮັດບາງສິ່ງບາງຢ່າງ: ຫມັ້ນສັນຍາ, ທົດສອບ, ແນະນໍາບາງສິ່ງບາງຢ່າງ, ໃຫ້ການປະເມີນຂອງທ່ານ.

ໃນ​ຂະ​ນະ​ທີ່​ພວກ​ເຮົາ​ກໍາ​ລັງ​ກະ​ກຽມ​ສໍາ​ລັບ​ການ​ Saint HighLoad++, ເຊິ່ງຈະຈັດຂຶ້ນໃນວັນທີ 6 ແລະ 7 ເດືອນເມສາໃນ St. Petersburg, ແລະພວກເຮົາເຊື້ອເຊີນຜູ້ພັດທະນາລະບົບການໂຫຼດສູງ. ສະຫມັກຂໍເອົາບົດລາຍງານ. ຜູ້ເວົ້າທີ່ມີປະສົບການຮູ້ແລ້ວວ່າຈະເຮັດແນວໃດ, ແຕ່ສໍາລັບຜູ້ເວົ້າໃຫມ່ພວກເຮົາແນະນໍາໃຫ້ຢ່າງຫນ້ອຍ ພະຍາຍາມ. ການ​ເຂົ້າ​ຮ່ວມ​ກອງ​ປະ​ຊຸມ​ໃນ​ຖາ​ນະ​ເປັນ​ຜູ້​ເວົ້າ​ມີ​ຄວາມ​ໄດ້​ປຽບ​ຈໍາ​ນວນ​ຫນຶ່ງ​. ທ່ານສາມາດອ່ານອັນໃດ, ຕົວຢ່າງ, ໃນຕອນທ້າຍ ຫົວ​ຂໍ້​ນີ້.

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