ipipou: ຫຼາຍກ່ວາພຽງແຕ່ອຸໂມງທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດ

ພວກເຮົາເວົ້າຫຍັງກັບພຣະເຈົ້າຂອງ IPv6?

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

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

ມີ N tunneling protocols ສໍາລັບທຸກລົດຊາດ ແລະສີ:

• stylish, ຄົນອັບເດດ:, ໄວຫນຸ່ມ WireGuard
• multifunctional, ເຊັ່ນມີດສະວິດ, OpenVPN ແລະ SSH
• GRE ເກົ່າແລະບໍ່ຊົ່ວຮ້າຍ
• IPIP ທີ່​ງ່າຍ​ດາຍ​ທີ່​ສຸດ​, ໄວ​, ບໍ່​ໄດ້​ເຂົ້າ​ລະ​ຫັດ​ຫມົດ​
• ພັດທະນາຢ່າງຫ້າວຫັນ GENEVE
• ອື່ນໆຈໍານວນຫຼາຍ.

ແຕ່ຂ້ອຍເປັນນັກຂຽນໂປລແກລມ, ດັ່ງນັ້ນຂ້ອຍຈະເພີ່ມ N ພຽງແຕ່ສ່ວນຫນຶ່ງ, ແລະອອກຈາກການພັດທະນາໂປໂຕຄອນທີ່ແທ້ຈິງໃຫ້ກັບນັກພັດທະນາ Kommersant.

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

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

• ມັນຮຽກຮ້ອງໃຫ້ມີ IP ສາທາລະນະທັງສອງດ້ານ,
• ແລະບໍ່ມີການພິສູດຢືນຢັນສໍາລັບທ່ານ.

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

ແລະຫຼັງຈາກນັ້ນມື້ຫນຶ່ງ, ໃນຂະນະທີ່ອ່ານບົດຄວາມກ່ຽວກັບ ອຸໂມງທີ່ຮອງຮັບໂດຍພື້ນເມືອງ ໃນ Linux ຂ້ອຍໄດ້ຂ້າມ FOU (Foo-over-UDP), i.e. ໃດກໍ່ຕາມ, ຫໍ່ຢູ່ໃນ UDP. ມາຮອດປະຈຸບັນ, ຮອງຮັບພຽງແຕ່ IPIP ແລະ GUE (Generic UDP Encapsulation) ເທົ່ານັ້ນ.

“ນີ້​ແມ່ນ​ລູກ​ປືນ​ເງິນ! IPIP ງ່າຍໆແມ່ນພຽງພໍສໍາລັບຂ້ອຍ.” - ຂ້ອຍ​ຄິດ​ວ່າ.

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

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

ພວກເຮົາບໍ່ຕ້ອງການ script ຂອງທ່ານ!

ຕົກລົງ, ຖ້າທ່ານຮູ້ພອດສາທາລະນະແລະ IP ຂອງລູກຄ້າ (ຕົວຢ່າງ, ທຸກຄົນທີ່ຢູ່ເບື້ອງຫຼັງບໍ່ໄດ້ໄປບ່ອນໃດກໍ່ຕາມ, NAT ພະຍາຍາມສ້າງແຜນທີ່ພອດ 1-in-1), ທ່ານສາມາດສ້າງອຸໂມງ IPIP-over-FOU ດ້ວຍ. ປະຕິບັດຕາມຄໍາສັ່ງ, ໂດຍບໍ່ມີການສະຄິບໃດໆ.

ໃນເຊີບເວີ:

# Подгрузить модуль ядра FOU
modprobe fou

# Создать IPIP туннель с инкапсуляцией в FOU.
# Модуль ipip подгрузится автоматически.
ip link add name ipipou0 type ipip 
    remote 198.51.100.2 local 203.0.113.1 
    encap fou encap-sport 10000 encap-dport 20001 
    mode ipip dev eth0

# Добавить порт на котором будет слушать FOU для этого туннеля
ip fou add port 10000 ipproto 4 local 203.0.113.1 dev eth0

# Назначить IP адрес туннелю
ip address add 172.28.0.0 peer 172.28.0.1 dev ipipou0

# Поднять туннель
ip link set ipipou0 up

ກ່ຽວ​ກັບ​ລູກ​ຄ້າ​:

modprobe fou

ip link add name ipipou1 type ipip 
    remote 203.0.113.1 local 192.168.0.2 
    encap fou encap-sport 10001 encap-dport 10000 encap-csum 
    mode ipip dev eth0

# Опции local, peer, peer_port, dev могут не поддерживаться старыми ядрами, можно их опустить.
# peer и peer_port используются для создания соединения сразу при создании FOU-listener-а.
ip fou add port 10001 ipproto 4 local 192.168.0.2 peer 203.0.113.1 peer_port 10000 dev eth0

ip address add 172.28.0.1 peer 172.28.0.0 dev ipipou1

ip link set ipipou1 up

ບ່ອນທີ່

• ipipou* — ຊື່​ຂອງ​ການ​ໂຕ້​ຕອບ​ເຄືອ​ຂ່າຍ tunnel ທ້ອງ​ຖິ່ນ​
• 203.0.113.1 - ເຄື່ອງແມ່ຂ່າຍ IP ສາທາລະນະ
• 198.51.100.2 - IP ສາທາລະນະຂອງລູກຄ້າ
• 192.168.0.2 — IP ລູກ​ຄ້າ​ໄດ້​ຮັບ​ມອບ​ຫມາຍ​ໃຫ້​ກັບ​ການ​ໂຕ້​ຕອບ eth0​
• 10001 - ພອດລູກຄ້າທ້ອງຖິ່ນສໍາລັບ FOU
• 20001 - ທ່າເຮືອລູກຄ້າສາທາລະນະສໍາລັບ FOU
• 10000 - ພອດເຊີບເວີສາທາລະນະສໍາລັບ FOU
• encap-csum — ທາງ​ເລືອກ​ທີ່​ຈະ​ເພີ່ມ UDP checksum ກັບ​ຊອງ UDP encapsulated​; ສາມາດໄດ້ຮັບການທົດແທນໂດຍ noencap-csum, ບໍ່ຕ້ອງເວົ້າເຖິງ, ຄວາມສົມບູນໄດ້ຖືກຄວບຄຸມແລ້ວໂດຍຊັ້ນຫຸ້ມນອກ (ໃນຂະນະທີ່ຊຸດຢູ່ໃນອຸໂມງ)
• eth0 — ການໂຕ້ຕອບໃນທ້ອງຖິ່ນທີ່ອຸໂມງ ipip ຈະຖືກຜູກມັດ
• 172.28.0.1 - IP ຂອງ​ການ​ໂຕ້​ຕອບ tunnel ລູກ​ຄ້າ (ສ່ວນ​ຕົວ​)
• 172.28.0.0 - ອິນເຕີເຟດເຊີບເວີ tunnel IP (ສ່ວນຕົວ)

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

ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະຫັນທຸກສິ່ງທຸກຢ່າງກັບຄືນໄປບ່ອນແມ່ນເພື່ອ unload modules kernel: modprobe -r fou ipip

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

ມັນບໍ່ໄດ້ແນວໃດເຮັດວຽກ?

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

ໃນເຄື່ອງແມ່ຂ່າຍ (ຂ້າງກັບ IP ສາທາລະນະ), ເມື່ອ ipipou ເລີ່ມຕົ້ນ, ມັນສ້າງຕົວຈັດການແຖວ nfqueue ແລະ configure netfilter ເພື່ອໃຫ້ແພັກເກັດທີ່ຈໍາເປັນຖືກສົ່ງໄປບ່ອນທີ່ພວກເຂົາຄວນຈະເປັນ: packets ເລີ່ມຕົ້ນການເຊື່ອມຕໍ່ກັບແຖວ nfqueue, ແລະ [ເກືອບ]. ສ່ວນທີ່ເຫຼືອທັງຫມົດແມ່ນໄປຫາຜູ້ຟັງ FOU.

ສໍາລັບຜູ້ທີ່ບໍ່ຮູ້, nfqueue (ຫຼື NetfilterQueue) ແມ່ນສິ່ງພິເສດສໍາລັບນັກສມັກເລ່ນທີ່ບໍ່ຮູ້ວິທີການພັດທະນາ kernel modules, ເຊິ່ງການນໍາໃຊ້ netfilter (nftables / iptables) ຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນເສັ້ນທາງແພັກເກັດເຄືອຂ່າຍໄປຫາພື້ນທີ່ຂອງຜູ້ໃຊ້ແລະປຸງແຕ່ງຢູ່ທີ່ນັ້ນໂດຍໃຊ້. primitive ຫມາຍ​ຄວາມ​ວ່າ​ໃນ​ມື​: ປັບ​ປຸງ​ແກ້​ໄຂ (ທາງ​ເລືອກ​) ແລະ​ໃຫ້​ມັນ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ແກ່ນ​, ຫຼື​ປະ​ຖິ້ມ​ມັນ​.

ສໍາລັບບາງພາສາການຂຽນໂປລແກລມມີການຜູກມັດສໍາລັບການເຮັດວຽກກັບ nfqueue, ສໍາລັບ bash ບໍ່ມີ (heh, ບໍ່ແປກໃຈ), ຂ້ອຍຕ້ອງໃຊ້ python: ipipou ໃຊ້ NetfilterQueue.

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

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

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

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

IPIP-over-FOU ປົກກະຕິມີບັນຫາຫນຶ່ງອີກໃນເວລາທີ່ເຮັດວຽກກັບ NAT - ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະສ້າງສອງອຸໂມງ IPIP ທີ່ຖືກຫຸ້ມຢູ່ໃນ UDP ດ້ວຍ IP ດຽວກັນ, ເພາະວ່າໂມດູນ FOU ແລະ IPIP ແມ່ນຂ້ອນຂ້າງໂດດດ່ຽວຈາກກັນແລະກັນ. ເຫຼົ່ານັ້ນ. ຄູ່ລູກຄ້າທີ່ຢູ່ເບື້ອງຫຼັງ IP ສາທາລະນະດຽວກັນຈະບໍ່ສາມາດເຊື່ອມຕໍ່ພ້ອມໆກັນກັບເຄື່ອງແມ່ຂ່າຍດຽວກັນດ້ວຍວິທີນີ້. ໃນອະນາຄົດ, ອາດຈະເປັນ, ມັນຈະຖືກແກ້ໄຂໃນລະດັບແກ່ນ, ແຕ່ນີ້ບໍ່ແນ່ນອນ. ໃນເວລານີ້, ບັນຫາ NAT ສາມາດແກ້ໄຂໄດ້ໂດຍ NAT - ຖ້າມັນເກີດຂື້ນວ່າຄູ່ຂອງທີ່ຢູ່ IP ໄດ້ຖືກຄອບຄອງໂດຍອຸໂມງອື່ນ, ipipou ຈະເຮັດ NAT ຈາກສາທາລະນະໄປຫາ IP ສ່ວນຕົວທາງເລືອກ, voila! - ທ່ານ​ສາ​ມາດ​ສ້າງ tunnels ຈົນ​ກ​່​ວາ​ພອດ​ຫມົດ​.

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

ຖ້າໃຜມີແນວຄວາມຄິດກ່ຽວກັບວິທີການແກ້ໄຂນີ້ໃນຂະນະທີ່ອອກຈາກສ່ວນໃຫຍ່ຂອງການຈະລາຈອນໃນຫຼັກ, ຢ່າລັງເລທີ່ຈະເວົ້າ.

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

ຕົວຢ່າງ, ນີ້ແມ່ນເຫດຜົນທີ່ວ່າ QUICK, ທີ່ HTTP / 3 ແມ່ນອີງໃສ່, ຖືກສ້າງຂື້ນຢູ່ເທິງສຸດຂອງ UDP, ແລະບໍ່ແມ່ນຢູ່ເທິງສຸດຂອງ IP.

ດີ, ຄໍາເວົ້າພຽງພໍ, ມັນເປັນເວລາທີ່ຈະເບິ່ງວ່າມັນເຮັດວຽກຢູ່ໃນ "ໂລກທີ່ແທ້ຈິງ".

ຮົບ

ໃຊ້ເພື່ອເຮັດແບບຢ່າງໃນໂລກແຫ່ງຄວາມເປັນຈິງ iperf3. ໃນແງ່ຂອງລະດັບຄວາມໃກ້ຊິດກັບຄວາມເປັນຈິງ, ນີ້ແມ່ນປະມານຄືກັນກັບການຈໍາລອງໂລກທີ່ແທ້ຈິງໃນ Minecraft, ແຕ່ສໍາລັບໃນປັດຈຸບັນມັນຈະເຮັດ.

ຜູ້​ເຂົ້າ​ຮ່ວມ​ການ​ແຂ່ງ​ຂັນ​:

• ອ້າງ​ອີງ​ຊ່ອງ​ທາງ​ຫຼັກ​
• hero ຂອງບົດຄວາມນີ້ແມ່ນ ipipou
• OpenVPN ດ້ວຍການພິສູດຢືນຢັນແຕ່ບໍ່ມີການເຂົ້າລະຫັດ
• OpenVPN ໃນໂໝດລວມທັງໝົດ
• WireGuard ໂດຍບໍ່ມີ PresharedKey, ດ້ວຍ MTU=1440 (ຕັ້ງແຕ່ IPv4 ເທົ່ານັ້ນ)

ຂໍ້ມູນດ້ານວິຊາການສໍາລັບ geeks
Metrics ຖືກປະຕິບັດດ້ວຍຄໍາສັ່ງຕໍ່ໄປນີ້:

ກ່ຽວ​ກັບ​ລູກ​ຄ້າ​:

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2 -u -b 12M; tail -1 "$CPULOG"
# Где "-b 12M" это пропускная способность основного канала, делённая на число потоков "-P", чтобы лишние пакеты не плодить и не портить производительность.

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2; tail -1 "$CPULOG"

ການຕອບສະໜອງ ICMP

ping -c 10 SERVER_IP | tail -1

ໃນເຊີບເວີ (ແລ່ນພ້ອມໆກັນກັບລູກຄ້າ):

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

ການຕັ້ງຄ່າອຸໂມງ

ipipou
server
/etc/ipipou/server.conf:

server
number 0
fou-dev eth0
fou-local-port 10000
tunl-ip 172.28.0.0
auth-remote-pubkey-b64 eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-secret topsecret
auth-lifetime 3600
reply-on-auth-ok
verb 3

systemctl start ipipou@server

ລູກ​ຄ້າ
/etc/ipipou/client.conf:

client
number 0
fou-local @eth0
fou-remote SERVER_IP:10000
tunl-ip 172.28.0.1
# pubkey of auth-key-b64: eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-key-b64 RuBZkT23na2Q4QH1xfmZCfRgSgPt5s362UPAFbecTso=
auth-secret topsecret
keepalive 27
verb 3

systemctl start ipipou@client

openvpn (ບໍ່ມີການເຂົ້າລະຫັດ, ດ້ວຍການພິສູດຢືນຢັນ)
server

openvpn --genkey --secret ovpn.key  # Затем надо передать ovpn.key клиенту
openvpn --dev tun1 --local SERVER_IP --port 2000 --ifconfig 172.16.17.1 172.16.17.2 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

ລູກ​ຄ້າ

openvpn --dev tun1 --local LOCAL_IP --remote SERVER_IP --port 2000 --ifconfig 172.16.17.2 172.16.17.1 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

openvpn (ດ້ວຍການເຂົ້າລະຫັດ, ການກວດສອບຄວາມຖືກຕ້ອງ, ຜ່ານ UDP, ທຸກຢ່າງຕາມທີ່ຄາດໄວ້)
ຕັ້ງຄ່າໂດຍໃຊ້ openvpn-ຈັດການ

ສາຍໄຟຟ້າ
server
/etc/wireguard/server.conf:

[Interface]
Address=172.31.192.1/18
ListenPort=51820
PrivateKey=aMAG31yjt85zsVC5hn5jMskuFdF8C/LFSRYnhRGSKUQ=
MTU=1440

[Peer]
PublicKey=LyhhEIjVQPVmr/sJNdSRqTjxibsfDZ15sDuhvAQ3hVM=
AllowedIPs=172.31.192.2/32

systemctl start wg-quick@server

ລູກ​ຄ້າ
/etc/wireguard/client.conf:

[Interface]
Address=172.31.192.2/18
PrivateKey=uCluH7q2Hip5lLRSsVHc38nGKUGpZIUwGO/7k+6Ye3I=
MTU=1440

[Peer]
PublicKey=DjJRmGvhl6DWuSf1fldxNRBvqa701c0Sc7OpRr4gPXk=
AllowedIPs=172.31.192.1/32
Endpoint=SERVER_IP:51820

systemctl start wg-quick@client

Результаты

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

proto bandwidth[Mbps] CPU_idle_client[%] CPU_idle_server[%]
# 20 Mbps канал с микрокомпьютера (4 core) до VPS (1 core) через Атлантику
# pure
UDP 20.4      99.80 93.34
TCP 19.2      99.67 96.68
ICMP latency min/avg/max/mdev = 198.838/198.997/199.360/0.372 ms
# ipipou
UDP 19.8      98.45 99.47
TCP 18.8      99.56 96.75
ICMP latency min/avg/max/mdev = 199.562/208.919/220.222/7.905 ms
# openvpn0 (auth only, no encryption)
UDP 19.3      99.89 72.90
TCP 16.1      95.95 88.46
ICMP latency min/avg/max/mdev = 191.631/193.538/198.724/2.520 ms
# openvpn (full encryption, auth, etc)
UDP 19.6      99.75 72.35
TCP 17.0      94.47 87.99
ICMP latency min/avg/max/mdev = 202.168/202.377/202.900/0.451 ms
# wireguard
UDP 19.3      91.60 94.78
TCP 17.2      96.76 92.87
ICMP latency min/avg/max/mdev = 217.925/223.601/230.696/3.266 ms

## около-1Gbps канал между VPS Европы и США (1 core)
# pure
UDP 729      73.40 39.93
TCP 363      96.95 90.40
ICMP latency min/avg/max/mdev = 106.867/106.994/107.126/0.066 ms
# ipipou
UDP 714      63.10 23.53
TCP 431      95.65 64.56
ICMP latency min/avg/max/mdev = 107.444/107.523/107.648/0.058 ms
# openvpn0 (auth only, no encryption)
UDP 193      17.51  1.62
TCP  12      95.45 92.80
ICMP latency min/avg/max/mdev = 107.191/107.334/107.559/0.116 ms
# wireguard
UDP 629      22.26  2.62
TCP 198      77.40 55.98
ICMP latency min/avg/max/mdev = 107.616/107.788/108.038/0.128 ms

ຊ່ອງ 20 Mbps

ຊ່ອງຕໍ່ 1 Gbps ໃນແງ່ດີ

ໃນທຸກກໍລະນີ, ipipou ແມ່ນຂ້ອນຂ້າງໃກ້ຊິດໃນການປະຕິບັດກັບຊ່ອງທາງພື້ນຖານ, ເຊິ່ງດີຫຼາຍ!

ອຸໂມງ openvpn ທີ່ບໍ່ເຂົ້າລະຫັດໄດ້ປະຕິບັດຕົວແປກໆໃນທັງສອງກໍລະນີ.

ຖ້າໃຜຈະໄປທົດສອບ ກໍ່ເປັນທີ່ສົນໃຈຢາກໄດ້ຟັງຄໍາຕິຊົມ.

ຂໍໃຫ້ IPv6 ແລະ NetPrickle ຢູ່ກັບພວກເຮົາ!

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