ipipou: ច្រើនជាងគ្រាន់តែជាផ្លូវរូងក្រោមដីដែលមិនបានអ៊ិនគ្រីប

តើយើងកំពុងនិយាយអ្វីទៅកាន់ព្រះជាម្ចាស់នៃ IPv6?

ត្រូវហើយ យើងនឹងនិយាយដូចគ្នាចំពោះព្រះនៃការអ៊ិនគ្រីបថ្ងៃនេះ។

នៅទីនេះយើងនឹងនិយាយអំពីផ្លូវរូងក្រោមដី IPv4 ដែលមិនបានអ៊ិនគ្រីប ប៉ុន្តែមិនមែនអំពី "ចង្កៀងក្តៅ" ទេ ប៉ុន្តែអំពី "LED" ទំនើបមួយ។ ហើយមានរន្ធឆៅផងដែរនៅទីនេះ ហើយការងារកំពុងដំណើរការជាមួយកញ្ចប់ព័ត៌មានក្នុងទំហំអ្នកប្រើប្រាស់។

មានពិធីការផ្លូវរូងក្រោមដី N សម្រាប់គ្រប់រសជាតិ និងពណ៌៖

• ទាន់សម័យ ទាន់សម័យ យុវវ័យ WireGuard
• ពហុមុខងារដូចជាកាំបិតស្វីស OpenVPN និង SSH
• ចាស់ហើយមិនអាក្រក់ GRE
• IPIP ដែលមិនមានការអ៊ិនគ្រីបទាំងស្រុង សាមញ្ញ លឿនបំផុត
• អភិវឌ្ឍយ៉ាងសកម្ម ហ្សឺណែវ
• ជាច្រើនទៀត។

ប៉ុន្តែខ្ញុំជាអ្នកសរសេរកម្មវិធី ដូច្នេះខ្ញុំនឹងបង្កើន N ដោយប្រភាគ ហើយទុកការអភិវឌ្ឍន៍នៃពិធីការពិតប្រាកដទៅអ្នកអភិវឌ្ឍន៍ Kommersant ។

នៅក្នុងទារកដែលមិនទាន់កើត សេចក្តីព្រាងអ្វី​ដែល​ខ្ញុំ​កំពុង​ធ្វើ​នៅ​ពេល​នេះ​គឺ​ដើម្បី​ទៅ​ដល់​ម្ចាស់​ផ្ទះ​នៅ​ពី​ក្រោយ NAT ពី​ខាង​ក្រៅ។ ដោយប្រើពិធីការជាមួយការគ្រីបមនុស្សពេញវ័យសម្រាប់រឿងនេះ ខ្ញុំមិនអាចធ្វើឱ្យអារម្មណ៍ដែលថាវាដូចជាការបាញ់ចាបចេញពីកាណុងនោះទេ។ ដោយសារតែ ផ្លូវរូងក្រោមដីត្រូវបានប្រើសម្រាប់ផ្នែកភាគច្រើនដើម្បីចាក់រន្ធនៅក្នុង NAT-e ចរាចរខាងក្នុងជាធម្មតាត្រូវបានអ៊ិនគ្រីបផងដែរ ប៉ុន្តែពួកគេនៅតែលង់ក្នុង HTTPS ។

ខណៈពេលដែលកំពុងស្រាវជ្រាវពិធីការផ្លូវរូងក្រោមដីផ្សេងៗ ការយកចិត្តទុកដាក់របស់អ្នកជំនាញផ្នែកខាងក្នុងរបស់ខ្ញុំត្រូវបានទាញទៅ IPIP ម្តងហើយម្តងទៀត ដោយសារតែការចំណាយតិចតួចបំផុត។ ប៉ុន្តែ​វា​មាន​គុណវិបត្តិ​សំខាន់​មួយ​កន្លះ​សម្រាប់​កិច្ចការ​របស់​ខ្ញុំ៖

• វាទាមទារ IP សាធារណៈទាំងសងខាង
• ហើយគ្មានការផ្ទៀងផ្ទាត់សម្រាប់អ្នកទេ។

ហេតុដូច្នេះហើយ អ្នកដែលល្អឥតខ្ចោះត្រូវបានរុញច្រានចូលទៅក្នុងជ្រុងងងឹតនៃលលាដ៍ក្បាល ឬកន្លែងណាដែលគាត់អង្គុយនៅទីនោះ។

ហើយបន្ទាប់មកថ្ងៃមួយ ខណៈពេលដែលកំពុងអានអត្ថបទ ផ្លូវរូងក្រោមដីដែលគាំទ្រ នៅក្នុងលីនុចខ្ញុំបានឆ្លងកាត់ FOU (Foo-over-UDP) ពោលគឺឧ។ អ្វីក៏ដោយ រុំក្នុង UDP ។ រហូតមកដល់ពេលនេះ មានតែ IPIP និង GUE (Generic UDP Encapsulation) ប៉ុណ្ណោះដែលត្រូវបានគាំទ្រ។

“នេះគឺជាគ្រាប់កាំភ្លើង! IPIP សាមញ្ញគឺគ្រប់គ្រាន់សម្រាប់ខ្ញុំ។ - ខ្ញុំ​គិត។

តាម​ពិត គ្រាប់​កាំភ្លើង​បាន​ប្រែ​ទៅ​ជា​មិន​មាន​ប្រាក់​ទាំង​ស្រុង​ទេ។ Encapsulation នៅក្នុង UDP ដោះស្រាយបញ្ហាដំបូង - អ្នកអាចភ្ជាប់ទៅអតិថិជនដែលនៅពីក្រោយ NAT ពីខាងក្រៅដោយប្រើការតភ្ជាប់ដែលបានបង្កើតជាមុន ប៉ុន្តែនៅទីនេះពាក់កណ្តាលនៃគុណវិបត្តិបន្ទាប់នៃ IPIP រីកដុះដាលនៅក្នុងពន្លឺថ្មី - នរណាម្នាក់ពីបណ្តាញឯកជនអាចលាក់នៅពីក្រោយអ្វីដែលអាចមើលឃើញ។ IP សាធារណៈ និងច្រកម៉ាស៊ីនភ្ញៀវ (នៅក្នុង IPIP សុទ្ធ បញ្ហានេះមិនមានទេ)។

ដើម្បីដោះស្រាយបញ្ហាមួយកន្លះនេះ ឧបករណ៍ប្រើប្រាស់បានកើតមក អាយភីពូ. វាអនុវត្តយន្តការផលិតនៅផ្ទះសម្រាប់ការផ្ទៀងផ្ទាត់ម៉ាស៊ីនពីចម្ងាយដោយមិនរំខានដល់ប្រតិបត្តិការនៃខឺណែល FOU ដែលនឹងដំណើរការកញ្ចប់ព័ត៌មានយ៉ាងរហ័ស និងប្រកបដោយប្រសិទ្ធភាពក្នុងចន្លោះខឺណែល។

យើងមិនត្រូវការស្គ្រីបរបស់អ្នកទេ!

យល់ព្រម ប្រសិនបើអ្នកស្គាល់ច្រកសាធារណៈ និង 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* - ឈ្មោះចំណុចប្រទាក់បណ្តាញផ្លូវរូងក្រោមដីក្នុងតំបន់
• 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 ដែលរុំព័ទ្ធ។ អាចត្រូវបានជំនួសដោយ noencap-csumមិនមែននិយាយទេ សុចរិតភាពត្រូវបានគ្រប់គ្រងដោយស្រទាប់រុំព័ទ្ធខាងក្រៅ (ខណៈពេលដែលកញ្ចប់ព័ត៌មានស្ថិតនៅខាងក្នុងផ្លូវរូងក្រោមដី)
• eth0 - ចំណុចប្រទាក់មូលដ្ឋានដែលផ្លូវរូងក្រោមដី ipip នឹងត្រូវបានចង
• 172.28.0.1 - IP នៃចំណុចប្រទាក់ផ្លូវរូងក្រោមដីរបស់អតិថិជន (ឯកជន)
• 172.28.0.0 - ចំណុចប្រទាក់ IP tunnel server (ឯកជន)

ដរាបណាការភ្ជាប់ UDP នៅមានជីវិត ផ្លូវរូងក្រោមដីនឹងដំណើរការ ប៉ុន្តែប្រសិនបើវាដាច់ អ្នកនឹងសំណាង - ប្រសិនបើ IP របស់អតិថិជន៖ ច្រកនៅតែដដែល - វានឹងរស់នៅ ប្រសិនបើពួកគេផ្លាស់ប្តូរ - វានឹងខូច។

មធ្យោបាយងាយស្រួលបំផុតដើម្បីបង្វែរអ្វីៗទាំងអស់មកវិញគឺដើម្បីដោះចេញម៉ូឌុលខឺណែល៖ modprobe -r fou ipip

ទោះបីជាការផ្ទៀងផ្ទាត់មិនត្រូវបានទាមទារក៏ដោយ IP និងច្រកសាធារណៈរបស់អតិថិជនមិនតែងតែត្រូវបានគេស្គាល់ទេ ហើយជារឿយៗមិនអាចទាយទុកជាមុនបាន ឬអថេរ (អាស្រ័យលើប្រភេទ NAT)។ ប្រសិនបើអ្នកបោះបង់ចោល encap-dport នៅផ្នែកខាងម៉ាស៊ីនមេ ផ្លូវរូងក្រោមដីនឹងមិនដំណើរការទេ វាមិនឆ្លាតគ្រប់គ្រាន់ក្នុងការយកច្រកតភ្ជាប់ពីចម្ងាយនោះទេ។ ក្នុងករណីនេះ ipipou ក៏អាចជួយបានដែរ ឬ WireGuard និងអ្នកផ្សេងទៀតដូចជាវាអាចជួយអ្នកបាន។

តើវាដំណើរការយ៉ាងដូចម្តេច?

ម៉ាស៊ីនភ្ញៀវ (ដែលជាធម្មតានៅពីក្រោយ NAT) បើកផ្លូវរូងក្រោមដីមួយ (ដូចក្នុងឧទាហរណ៍ខាងលើ) ហើយផ្ញើកញ្ចប់ព័ត៌មានផ្ទៀងផ្ទាត់ទៅម៉ាស៊ីនមេ ដើម្បីឱ្យវាកំណត់រចនាសម្ព័ន្ធផ្លូវរូងក្រោមដីនៅចំហៀងរបស់វា។ អាស្រ័យលើការកំណត់ នេះអាចជាកញ្ចប់ទទេ (គ្រាន់តែដើម្បីឱ្យម៉ាស៊ីនមេអាចមើលឃើញ IP សាធារណៈ៖ ច្រកតភ្ជាប់) ឬជាមួយទិន្នន័យដែលម៉ាស៊ីនមេអាចកំណត់អត្តសញ្ញាណអតិថិជន។ ទិន្នន័យអាចជាឃ្លាសម្ងាត់សាមញ្ញក្នុងអត្ថបទច្បាស់លាស់ (ភាពស្រដៀងគ្នាជាមួយ HTTP Basic Auth ចូលមកក្នុងចិត្ត) ឬទិន្នន័យដែលបានរចនាជាពិសេសដែលបានចុះហត្ថលេខាជាមួយសោឯកជន (ស្រដៀងទៅនឹង HTTP Digest Auth ខ្លាំងជាង សូមមើលមុខងារ client_auth នៅក្នុងលេខកូដ) ។

នៅលើម៉ាស៊ីនមេ (ផ្នែកខាងជាមួយ IP សាធារណៈ) នៅពេលដែល ipipou ចាប់ផ្តើម វាបង្កើតឧបករណ៍ដោះស្រាយជួរ nfqueue និងកំណត់រចនាសម្ព័ន្ធ netfilter ដូច្នេះកញ្ចប់ព័ត៌មានចាំបាច់ត្រូវបានផ្ញើទៅកន្លែងដែលពួកគេគួរតែជា៖ កញ្ចប់ចាប់ផ្តើមការតភ្ជាប់ទៅជួរ nfqueue ហើយ [ស្ទើរតែ] នៅសល់ទាំងអស់ទៅត្រង់អ្នកស្តាប់ FOU ។

សម្រាប់អ្នកដែលមិនដឹង nfqueue (ឬ NetfilterQueue) គឺជារឿងពិសេសសម្រាប់អ្នកស្ម័គ្រចិត្តដែលមិនដឹងពីរបៀបបង្កើតម៉ូឌុលខឺណែល ដែលការប្រើប្រាស់ netfilter (nftables/iptables) អនុញ្ញាតឱ្យអ្នកប្តូរទិសកញ្ចប់បណ្តាញទៅកាន់កន្លែងអ្នកប្រើប្រាស់ ហើយដំណើរការវានៅទីនោះដោយប្រើ មធ្យោបាយបុព្វកាលនៅនឹងដៃ៖ កែប្រែ (ជាជម្រើស) ហើយប្រគល់វាទៅខឺណែលវិញ ឬបោះវាចោល។

សម្រាប់ភាសាសរសេរកម្មវិធីមួយចំនួនមានការចងសម្រាប់ធ្វើការជាមួយ nfqueue សម្រាប់ bash មិនមានទេ (ហេហេ មិនគួរឱ្យភ្ញាក់ផ្អើលទេ) ខ្ញុំត្រូវប្រើ python: ipipou ប្រើ NetfilterQueue.

ប្រសិនបើការអនុវត្តមិនសំខាន់ទេ ដោយប្រើវត្ថុនេះ អ្នកអាចបង្កើតតក្កវិជ្ជាផ្ទាល់ខ្លួនរបស់អ្នកបានយ៉ាងរហ័ស និងងាយស្រួលសម្រាប់ធ្វើការជាមួយកញ្ចប់ព័ត៌មានក្នុងកម្រិតទាប ឧទាហរណ៍ បង្កើតពិធីការផ្ទេរទិន្នន័យពិសោធន៍ ឬ troll សេវាក្នុងស្រុក និងពីចម្ងាយជាមួយនឹងអាកប្បកិរិយាមិនស្តង់ដារ។

រន្ធឆៅដំណើរការដោយដៃជាមួយ nfqueue ឧទាហរណ៍ នៅពេលដែលផ្លូវរូងក្រោមដីត្រូវបានកំណត់រចនាសម្ព័ន្ធរួចហើយ ហើយ FOU កំពុងស្តាប់នៅលើច្រកដែលចង់បាន អ្នកនឹងមិនអាចផ្ញើកញ្ចប់ព័ត៌មានពីច្រកដូចគ្នាតាមរបៀបធម្មតាបានទេ - វារវល់ ប៉ុន្តែ អ្នកអាចយក និងផ្ញើកញ្ចប់ព័ត៌មានដែលបង្កើតដោយចៃដន្យដោយផ្ទាល់ទៅកាន់ចំណុចប្រទាក់បណ្តាញដោយប្រើរន្ធឆៅ ទោះបីជាការបង្កើតកញ្ចប់ព័ត៌មានបែបនេះនឹងតម្រូវឱ្យមានការបន្ថែមតិចតួចក៏ដោយ។ នេះជារបៀបដែលកញ្ចប់ព័ត៌មានដែលមានការផ្ទៀងផ្ទាត់ត្រូវបានបង្កើតឡើងនៅក្នុង ipipou ។

ចាប់តាំងពី ipipou ដំណើរការតែកញ្ចប់ដំបូងពីការតភ្ជាប់ (និងអ្នកដែលគ្រប់គ្រងដើម្បីលេចធ្លាយចូលទៅក្នុងជួរមុនពេលការតភ្ជាប់ត្រូវបានបង្កើតឡើង) ការសម្តែងស្ទើរតែមិនទទួលរង។

ដរាបណាម៉ាស៊ីនមេ ipipou ទទួលបានកញ្ចប់ព័ត៌មានដែលបានផ្ទៀងផ្ទាត់ ផ្លូវរូងក្រោមដីមួយត្រូវបានបង្កើត ហើយកញ្ចប់ព័ត៌មានបន្តបន្ទាប់ទាំងអស់នៅក្នុងការតភ្ជាប់ត្រូវបានដំណើរការរួចហើយដោយខឺណែលឆ្លងកាត់ nfqueue ។ ប្រសិនបើការភ្ជាប់បរាជ័យ នោះកញ្ចប់ទីមួយនៃកញ្ចប់បន្ទាប់នឹងត្រូវបញ្ជូនទៅជួរ nfqueue អាស្រ័យលើការកំណត់ ប្រសិនបើវាមិនមែនជាកញ្ចប់ព័ត៌មានដែលមានការផ្ទៀងផ្ទាត់ ប៉ុន្តែពី IP និងច្រកម៉ាស៊ីនភ្ញៀវដែលបានចងចាំចុងក្រោយ វាអាចត្រូវបានឆ្លងកាត់។ នៅលើ ឬបោះចោល។ ប្រសិនបើកញ្ចប់ព័ត៌មានដែលផ្ទៀងផ្ទាត់បានមកពី IP និងច្រកថ្មី ផ្លូវរូងក្រោមដីត្រូវបានតំឡើងឡើងវិញដើម្បីប្រើពួកវា។

IPIP-over-FOU ធម្មតាមានបញ្ហាមួយទៀតនៅពេលធ្វើការជាមួយ NAT - វាមិនអាចទៅរួចទេក្នុងការបង្កើតផ្លូវរូងក្រោមដី IPIP ពីរដែលរុំព័ទ្ធក្នុង UDP ជាមួយ IP ដូចគ្នា ពីព្រោះម៉ូឌុល FOU និង IPIP គឺដាច់ឆ្ងាយពីគ្នាទៅវិញទៅមក។ ទាំងនោះ។ អតិថិជនមួយគូដែលនៅពីក្រោយ IP សាធារណៈដូចគ្នានឹងមិនអាចតភ្ជាប់ក្នុងពេលដំណាលគ្នាទៅម៉ាស៊ីនមេដូចគ្នាតាមរបៀបនេះទេ។ នៅ​ពេល​អនាគត, អាចធ្វើទៅបានវានឹងត្រូវបានដោះស្រាយនៅកម្រិតខឺណែល ប៉ុន្តែនេះមិនប្រាកដទេ។ ក្នុងពេលនេះបញ្ហា NAT អាចត្រូវបានដោះស្រាយដោយ NAT - ប្រសិនបើវាកើតឡើងថាអាសយដ្ឋាន IP មួយគូត្រូវបានកាន់កាប់ដោយផ្លូវរូងក្រោមដីផ្សេងទៀត ipipou នឹងធ្វើ NAT ពីសាធារណៈទៅជា IP ឯកជនជំនួសវិញ voila! - អ្នកអាចបង្កើតផ្លូវរូងក្រោមដីរហូតដល់ច្រកអស់។

ដោយសារតែ មិនមែនកញ្ចប់ព័ត៌មានទាំងអស់នៅក្នុងការតភ្ជាប់ត្រូវបានចុះហត្ថលេខាទេ នោះការការពារដ៏សាមញ្ញនេះងាយរងគ្រោះចំពោះ MITM ដូច្នេះប្រសិនបើមានជនខិលខូចលាក់ខ្លួននៅលើផ្លូវរវាងម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេ ដែលអាចស្តាប់ចរាចរណ៍ និងរៀបចំវាបាន គាត់អាចប្តូរទិសកញ្ចប់ព័ត៌មានដែលបានផ្ទៀងផ្ទាត់តាមរយៈ អាសយដ្ឋានមួយផ្សេងទៀត និងបង្កើតផ្លូវរូងក្រោមដីពីម៉ាស៊ីនដែលមិនគួរឱ្យទុកចិត្ត។

ប្រសិនបើអ្នកណាម្នាក់មានគំនិតអំពីរបៀបជួសជុលនេះ ខណៈពេលដែលចាកចេញពីចរាចរណ៍ភាគច្រើននៅក្នុងស្នូល សូមកុំស្ទាក់ស្ទើរក្នុងការនិយាយ។

ដោយវិធីនេះ encapsulation នៅក្នុង UDP បានបង្ហាញខ្លួនឯងយ៉ាងល្អ។ បើប្រៀបធៀបទៅនឹងការរុំព័ទ្ធលើ IP វាមានស្ថេរភាពជាង ហើយជារឿយៗលឿនជាង ទោះបីជាមានបន្ថែមពីលើក្បាល UDP ក៏ដោយ។ នេះគឺដោយសារតែការពិតដែលថាម៉ាស៊ីនភាគច្រើននៅលើអ៊ីនធឺណិតដំណើរការបានល្អតែជាមួយពិធីការពេញនិយមបំផុតចំនួនបីគឺ TCP, UDP, ICMP ។ ផ្នែកជាក់ស្តែងអាចបោះបង់អ្វីៗផ្សេងទៀតទាំងស្រុង ឬដំណើរការវាកាន់តែយឺត ព្រោះវាត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់តែទាំងបីនេះប៉ុណ្ណោះ។

ជាឧទាហរណ៍ នេះជាមូលហេតុដែល QUICK ដែល HTTP/3 ត្រូវបានបង្កើតឡើងនៅលើកំពូល UDP ហើយមិនមែននៅលើ IP នោះទេ។

ជាការប្រសើរណាស់, ពាក្យគ្រប់គ្រាន់, វាដល់ពេលហើយដើម្បីមើលពីរបៀបដែលវាដំណើរការនៅក្នុង "ពិភពពិត" ។

សមរភូមិ

ប្រើដើម្បីត្រាប់តាមពិភពពិត iperf3. បើនិយាយពីកម្រិតនៃភាពស្និទ្ធស្នាលនឹងការពិត នេះគឺប្រហាក់ប្រហែលនឹងការត្រាប់តាមពិភពពិតនៅក្នុង Minecraft ប៉ុន្តែសម្រាប់ពេលនេះវានឹងធ្វើបាន។

អ្នកចូលរួមក្នុងការប្រកួត៖

• ឆានែលសំខាន់យោង
• វីរបុរសនៃអត្ថបទនេះគឺ ipipou
• OpenVPN ជាមួយការផ្ទៀងផ្ទាត់ ប៉ុន្តែគ្មានការអ៊ិនគ្រីបទេ។
• OpenVPN នៅក្នុងរបៀបរួមបញ្ចូលទាំងអស់។
• WireGuard ដោយគ្មាន PresharedKey ជាមួយ MTU=1440 (ចាប់តាំងពី IPv4 តែប៉ុណ្ណោះ)

ទិន្នន័យបច្ចេកទេសសម្រាប់ geeks
ម៉ែត្រត្រូវបានយកដោយប្រើពាក្យបញ្ជាដូចខាងក្រោមៈ

នៅលើអតិថិជន៖

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"

ការកំណត់រចនាសម្ព័ន្ធផ្លូវរូងក្រោមដី

អាយភីពូ
ម៉ាស៊ីនមេ
/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 (គ្មានការអ៊ិនគ្រីបជាមួយការផ្ទៀងផ្ទាត់)
ម៉ាស៊ីនមេ

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-គ្រប់គ្រង

អ្នកការពារខ្សែ
ម៉ាស៊ីនមេ
/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 របស់ Server មិនមែនជាការចង្អុលបង្ហាញខ្លាំងនោះទេ ដោយសារតែ... មានសេវាកម្មជាច្រើនទៀតដែលកំពុងដំណើរការនៅទីនោះ ពេលខ្លះពួកគេស៊ីធនធាន៖

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