ຄໍາຕອບລາຍລະອຽດກ່ຽວກັບຄໍາເຫັນ, ເຊັ່ນດຽວກັນກັບເລັກນ້ອຍກ່ຽວກັບຊີວິດຂອງຜູ້ໃຫ້ບໍລິການໃນສະຫະພັນລັດເຊຍ

ກະຕຸ້ນຂ້ອຍໃຫ້ໂພສນີ້ ນີ້ແມ່ນຄໍາເຫັນ.

ຂ້າພະເຈົ້າອ້າງເຖິງມັນຢູ່ທີ່ນີ້:

ກະເລມັນ ມື້ນີ້ ເວລາ 18:53 ໂມງ

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

ຄວາມຈິງແມ່ນວ່າມັນເບິ່ງຄືວ່າພວກເຮົາເປັນຜູ້ໃຫ້ບໍລິການດຽວກັນ :)

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

ສິ່ງທີ່ຕໍ່ໄປນີ້ຈະແບ່ງອອກເປັນສອງສ່ວນ:

1. ເຫດຜົນສໍາລັບບັນຫາໃນປະຈຸບັນຂອງພວກເຮົາກັບ mail.ru ແລະການສະແຫວງຫາທີ່ຫນ້າຕື່ນເຕັ້ນເພື່ອຊອກຫາພວກມັນ
2. ການມີຢູ່ຂອງ ISP ໃນຄວາມເປັນຈິງຂອງມື້ນີ້, ຄວາມຫມັ້ນຄົງຂອງ RuNet ອະທິປະໄຕ.

ບັນຫາການເຂົ້າເຖິງກັບ mail.ru

ໂອ້, ມັນເປັນເລື່ອງທີ່ຂ້ອນຂ້າງຍາວ.

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

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

ສອງສາມມື້ກ່ອນຫນ້ານີ້ພວກເຮົາໄດ້ເປີດໃຊ້ການກັ່ນຕອງຫ້າມໃສ່ມັນ (ໃນຂະນະທີ່ເຮັດໃຫ້ລະບົບເກົ່າເຮັດວຽກ) - ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າຈະດີ.

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

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

ພວກເຂົາເລີ່ມກວດເບິ່ງ: ບາງສິ່ງບາງຢ່າງຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ ບາງຄັ້ງ, ບາງຄັ້ງຄາວ ສົ່ງ TCP RST ໃນການຕອບສະຫນອງຕໍ່ການຮ້ອງຂໍສະເພາະກັບເຄືອຂ່າຍ mail.ru. ຍິ່ງໄປກວ່ານັ້ນ, ມັນສົ່ງການຜະລິດທີ່ບໍ່ຖືກຕ້ອງ (ໂດຍບໍ່ມີ ACK), ແນ່ນອນ TCP RST ປອມ. ນີ້ແມ່ນສິ່ງທີ່ເບິ່ງຄືວ່າ:

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

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

ປະການທໍາອິດ, ພວກເຮົາມີ uplinks sane ພຽງພໍເພື່ອວ່າພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງທົນທຸກເຊັ່ນນີ້ :)

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

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

• ການກັ່ນຕອງຖືກປິດໃຊ້ງານຢ່າງສົມບູນ
• NAT ຖືກປິດການນຳໃຊ້ດ້ວຍລະບົບໃໝ່
• PC ທົດສອບໄດ້ຖືກຈັດໃສ່ໃນສະນຸກເກີທີ່ໂດດດ່ຽວແຍກຕ່າງຫາກ
• ປ່ຽນທີ່ຢູ່ IP

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

ໃນທີ່ສຸດ, ຜູ້ຕາງຫນ້າຂອງຜູ້ຂາຍໄດ້ລະບຸຢ່າງຫມັ້ນໃຈວ່າຮາດແວບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບມັນ: rsts ແມ່ນມາຈາກບ່ອນໃດຫນຶ່ງທີ່ສູງກວ່າ.

Примечаниеໃນຈຸດນີ້, ບາງຄົນອາດຈະເວົ້າວ່າ: ແຕ່ມັນງ່າຍຂຶ້ນຫຼາຍທີ່ຈະເອົາຂີ້ເຫຍື້ອຈາກ PC ທົດສອບ, ແຕ່ຈາກທາງດ່ວນຂ້າງເທິງ DPI?

ບໍ່, ແຕ່ຫນ້າເສຍດາຍ, ການຖິ້ມຂີ້ເຫຍື້ອ (ແລະແມ້ກະທັ້ງພຽງແຕ່ສະທ້ອນ) 40+gbps ບໍ່ແມ່ນເລື່ອງເລັກນ້ອຍ.

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

ຂ້າພະເຈົ້າໄດ້ເບິ່ງວ່າ IX ການຈະລາຈອນກັບເຄືອຂ່າຍ MRG ໃນປັດຈຸບັນແມ່ນຜ່ານແລະພຽງແຕ່ຍົກເລີກກອງປະຊຸມ bgp ກັບມັນ. ແລະ - ເບິ່ງ​ແມ! - ທຸກຢ່າງກັບຄືນສູ່ສະພາບປົກກະຕິທັນທີ 🙁

ໃນດ້ານຫນຶ່ງ, ມັນເປັນເລື່ອງທີ່ຫນ້າອັບອາຍທີ່ຫມົດມື້ໄດ້ໃຊ້ເວລາໃນການຊອກຫາບັນຫາ, ເຖິງແມ່ນວ່າມັນຖືກແກ້ໄຂໃນຫ້ານາທີ.

ອີກດ້ານຫນຶ່ງ:

— ໃນຄວາມຊົງຈໍາຂອງຂ້ອຍ, ນີ້ແມ່ນສິ່ງທີ່ບໍ່ເຄີຍມີມາກ່ອນ. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ຂຽນໄວ້ຂ້າງເທິງ - IX ແທ້ ບໍ່ມີຈຸດໃດໃນການກັ່ນຕອງການຈະລາຈອນທາງຜ່ານ. ປົກກະຕິແລ້ວພວກມັນມີຫຼາຍຮ້ອຍ gigabits/terabits ຕໍ່ວິນາທີ. ຂ້າພະເຈົ້າພຽງແຕ່ບໍ່ສາມາດຈິນຕະນາການຢ່າງຈິງຈັງບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້ຈົນກ່ວາບໍ່ດົນມານີ້.

— ເປັນເຫດການບັງເອີນທີ່ໂຊກດີຢ່າງບໍ່ໜ້າເຊື່ອ: ຮາດແວທີ່ຊັບຊ້ອນໃໝ່ທີ່ບໍ່ເຊື່ອຖືໄດ້ໂດຍສະເພາະ ແລະຈາກທີ່ມັນບໍ່ຊັດເຈນວ່າສາມາດຄາດຫວັງຫຍັງໄດ້ — ປັບແຕ່ງສະເພາະເພື່ອສະກັດຊັບພະຍາກອນ, ລວມທັງ TCP RSTs.

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

ນີ້​ແມ່ນ​ຄວາມ​ພະ​ຍາ​ຍາມ​ເລັກ​ນ້ອຍ​ເພື່ອ​ໃຫ້​ຕົວ​ເອງ​, ກະ​ລຸ​ນາ​ເຂົ້າ​ໃຈ​ແລະ​ໃຫ້​ອະ​ໄພ :)

PS: ຂ້າພະເຈົ້າເຈດຕະນາບໍ່ຕັ້ງຊື່ຜູ້ຜະລິດ DPI / NAT ຫຼື IX (ໃນຄວາມເປັນຈິງ, ຂ້າພະເຈົ້າບໍ່ມີຄໍາຮ້ອງທຸກພິເສດກ່ຽວກັບພວກມັນ, ສິ່ງສໍາຄັນແມ່ນເຂົ້າໃຈວ່າມັນເປັນແນວໃດ)

ມື້ນີ້ (ເຊັ່ນດຽວກັນກັບມື້ວານນີ້ແລະມື້ກ່ອນມື້ວານນີ້) ຄວາມເປັນຈິງຈາກທັດສະນະຂອງຜູ້ໃຫ້ບໍລິການອິນເຕີເນັດ

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

ໃນພາກນີ້, ຂ້າພະເຈົ້າຈະພະຍາຍາມອະທິບາຍ "ວິວັດທະນາການ" ຂອງຫຼັກເຄືອຂ່າຍຂອງ ISP ປົກກະຕິໃນໄລຍະສິບປີທີ່ຜ່ານມາ.

ສິບປີກ່ອນ.

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

ໃນຮູບນີ້, ງ່າຍດາຍຫຼາຍ, ບໍ່ມີລໍາຕົ້ນ, ແຫວນ, ip/mpls routing.

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

ໂຄງ​ການ​ດັ່ງ​ກ່າວ​ແມ່ນ​ຫຼາຍ​, ງ່າຍ​ທີ່​ຈະ​ສະ​ຫງວນ​ທັງ​ໃນ L3 (ເສັ້ນ​ທາງ​ເຄື່ອນ​ໄຫວ​) ແລະ L2 (MPLS​)​.

ທ່ານ​ສາ​ມາດ​ຕິດ​ຕັ້ງ N+1 ຂອງ​ສິ່ງ​ໃດ​ຫນຶ່ງ​: ການ​ເຂົ້າ​ເຖິງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​, ສະ​ຫຼັບ​, ຊາຍ​ແດນ - ແລະ​ທາງ​ຫນຶ່ງ​ຫຼື​ອື່ນໆ​ສະ​ຫງວນ​ໃຫ້​ເຂົາ​ເຈົ້າ​ສໍາ​ລັບ​ການ​ລົ້ມ​ເຫຼວ​ອັດ​ຕະ​ໂນ​ມັດ​.

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

ມີຄວາມຕ້ອງການອັນຮີບດ່ວນເພື່ອຊອກຫາວິທີການກັ່ນຕອງການເຂົ້າຊົມຂອງຜູ້ໃຊ້.

ມີວິທີການທີ່ແຕກຕ່າງກັນຢູ່ທີ່ນີ້.

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

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

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

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

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

ຂ້ອຍຢາກພູມໃຈ, ແຕ່ໂສກເສົ້າເລັກນ້ອຍ =)

ໃນປັດຈຸບັນທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່ານີ້:

ໃນອີກສອງສາມປີ ທຸກຄົນມີຜູ້ກວດສອບແລ້ວ; ມີຊັບພະຍາກອນຫຼາຍຂື້ນຢູ່ໃນທະບຽນ. ສໍາລັບບາງອຸປະກອນທີ່ເກົ່າແກ່ (ຕົວຢ່າງ Cisco 7600), ໂຄງການ "ການກັ່ນຕອງຂ້າງຄຽງ" ພຽງແຕ່ບໍ່ສາມາດໃຊ້ໄດ້: ຈໍານວນເສັ້ນທາງໃນ 76 ແພລະຕະຟອມຖືກຈໍາກັດພຽງແຕ່ເກົ້າແສນ, ໃນຂະນະທີ່ຈໍານວນເສັ້ນທາງ IPv4 ດຽວມື້ນີ້ກໍາລັງເຂົ້າຫາ 800. ພັນ. ແລະຖ້າມັນຍັງເປັນ ipv6 ... ແລະອີກ ... ເທົ່າໃດ? 900000 ທີ່ຢູ່ສ່ວນບຸກຄົນໃນການຫ້າມ RKN? =)

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

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

ຜູ້ໃຫ້ບໍລິການຫຼາຍກວ່າແລະຫຼາຍໄດ້ຖືກບັງຄັບໃຫ້ຕິດຕັ້ງລະບົບ DPI ຂອງລະດັບຄວາມຫນ້າເຊື່ອຖືທີ່ແຕກຕ່າງກັນໃນທົ່ວທາງດ່ວນ.

ນຶ່ງປີ ຫຼືສອງປີກ່ອນ ອີງຕາມຂ່າວລື, ເກືອບທັງຫມົດ FSB ເລີ່ມຕ້ອງການການຕິດຕັ້ງອຸປະກອນຕົວຈິງ ໂສມ (ກ່ອນຫນ້ານີ້, ຜູ້ໃຫ້ບໍລິການສ່ວນໃຫຍ່ຄຸ້ມຄອງດ້ວຍການອະນຸມັດຈາກເຈົ້າຫນ້າທີ່ ແຜນ SORM - ແຜນ​ການ​ຂອງ​ມາດ​ຕະ​ການ​ປະ​ຕິ​ບັດ​ໃນ​ກໍ​ລະ​ນີ​ທີ່​ຕ້ອງ​ການ​ຊອກ​ຫາ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​)

ນອກເຫນືອຈາກເງິນ (ບໍ່ແນ່ນອນ, ແຕ່ຍັງມີຫຼາຍລ້ານ), SORM ຕ້ອງການການຫມູນໃຊ້ຫຼາຍກັບເຄືອຂ່າຍ.

• SORM ຕ້ອງການເບິ່ງທີ່ຢູ່ຜູ້ໃຊ້ "ສີຂີ້ເຖົ່າ" ກ່ອນການແປພາສາ nat
• SORM ມີຈໍານວນຈໍາກັດຂອງການໂຕ້ຕອບເຄືອຂ່າຍ

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

ນັ້ນແມ່ນ, ງ່າຍດາຍຫຼາຍ, ມັນແມ່ນ (ຊ້າຍ) ທຽບກັບກາຍເປັນ (ຂວາ):

ໃນປັດຈຸບັນ ຜູ້ໃຫ້ບໍລິການສ່ວນໃຫຍ່ຍັງຮຽກຮ້ອງໃຫ້ມີການປະຕິບັດ SORM-3 - ເຊິ່ງລວມມີ, ໃນບັນດາສິ່ງອື່ນໆ, ການຕັດໄມ້ອອກອາກາດ nat.

ສໍາລັບຈຸດປະສົງເຫຼົ່ານີ້, ພວກເຮົາຍັງໄດ້ເພີ່ມອຸປະກອນແຍກຕ່າງຫາກສໍາລັບ NAT ກັບແຜນວາດຂ້າງເທິງ (ແນ່ນອນວ່າສິ່ງທີ່ໄດ້ສົນທະນາໃນພາກທໍາອິດ). ຍິ່ງໄປກວ່ານັ້ນ, ເພີ່ມໃນຄໍາສັ່ງທີ່ແນ່ນອນ: ເນື່ອງຈາກວ່າ SORM ຕ້ອງ "ເບິ່ງ" ການຈະລາຈອນກ່ອນທີ່ຈະແປທີ່ຢູ່, ການຈະລາຈອນຕ້ອງໄປຢ່າງເຂັ້ມງວດດັ່ງຕໍ່ໄປນີ້: ຜູ້ໃຊ້ -> ສະຫຼັບ, kernel -> ເຂົ້າເຖິງເຄື່ອງແມ່ຂ່າຍ -> SORM -> NAT -> switching, kernel - > ອິນເຕີເນັດ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຕ້ອງ "ຫັນ" ການໄຫຼວຽນຂອງການຈະລາຈອນໃນທິດທາງອື່ນເພື່ອກໍາໄລ, ເຊິ່ງກໍ່ມີຄວາມຫຍຸ້ງຍາກຫຼາຍ.

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

ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ນີ້​ສາ​ມາດ​ໄດ້​ຮັບ​ການ extrapolated ຂ້ອນ​ຂ້າງ​ໂປ່ງ​ໃສ​ກັບ​ການ​ລິ​ເລີ່ມ​ໃນ​ປັດ​ຈຸ​ບັນ​ເພື່ອ​ອະ​ທິ​ປະ​ໄຕ Runet​, ປົກ​ປັກ​ຮັກ​ສາ​ມັນ​, ສະ​ຖຽນ​ລະ​ພາບ​ແລະ​ປັບ​ປຸງ​ມັນ :)

ແລະ Yarovaya ຍັງຢູ່ຂ້າງຫນ້າ.

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