ការប្តូរពី OpenVPN ទៅ WireGuard ដើម្បីបញ្ចូលគ្នានូវបណ្តាញចូលទៅក្នុងបណ្តាញ L2 មួយ។

ខ្ញុំចង់ចែករំលែកបទពិសោធន៍របស់ខ្ញុំក្នុងការរួមបញ្ចូលបណ្តាញនៅក្នុងអាផាតមិនដាច់ស្រយាលតាមភូមិសាស្រ្តចំនួនបី ដែលនីមួយៗប្រើរ៉ោតទ័រ OpenWRT ជាច្រកផ្លូវចូលទៅក្នុងបណ្តាញរួមមួយ។ នៅពេលជ្រើសរើសវិធីសាស្រ្តសម្រាប់ការបញ្ចូលគ្នានៃបណ្តាញរវាង L3 ជាមួយ subnet routing និង L2 ជាមួយ bridging នៅពេលដែលថ្នាំងបណ្តាញទាំងអស់នឹងនៅក្នុង subnet ដូចគ្នា ចំណូលចិត្តត្រូវបានផ្តល់អោយទៅ method ទីពីរដែលពិបាកកំណត់រចនាសម្ព័ន្ធ ប៉ុន្តែផ្តល់ឱកាសកាន់តែច្រើន ចាប់តាំងពី ការប្រើប្រាស់បច្ចេកវិទ្យាប្រកបដោយតម្លាភាពត្រូវបានគ្រោងទុកនៅក្នុងបណ្តាញដែលត្រូវបានបង្កើត Wake-on-Lan និង DLNA ។

ផ្នែកទី 1: ផ្ទៃខាងក្រោយ

OpenVPN ត្រូវបានជ្រើសរើសដំបូងជាពិធីការសម្រាប់ការអនុវត្តកិច្ចការនេះ ដោយសារដំបូង វាអាចបង្កើតឧបករណ៍ម៉ាស៊ីនដែលអាចបញ្ចូលទៅក្នុងស្ពានដោយគ្មានបញ្ហា ហើយទីពីរ OpenVPN គាំទ្រប្រតិបត្តិការលើពិធីការ TCP ដែលមានសារៈសំខាន់ផងដែរ ពីព្រោះគ្មាន នៃអាផាតមិនមានអាសយដ្ឋាន IP ជាក់លាក់មួយ ហើយខ្ញុំមិនអាចប្រើ STUN បានទេ ដោយសារអ្នកផ្តល់សេវារបស់ខ្ញុំដោយសារហេតុផលមួយចំនួនរារាំងការភ្ជាប់ UDP ចូលពីបណ្តាញរបស់ពួកគេ ខណៈពេលដែលពិធីការ TCP បានអនុញ្ញាតឱ្យខ្ញុំបញ្ជូនបន្តច្រកម៉ាស៊ីនមេ VPN ដើម្បីជួល VPS ដោយប្រើ SSH ។ បាទ វិធីសាស្រ្តនេះផ្តល់នូវបន្ទុកដ៏ធំមួយ ដោយសារទិន្នន័យត្រូវបានអ៊ិនគ្រីបពីរដង ប៉ុន្តែខ្ញុំមិនចង់ណែនាំ VPS ទៅក្នុងបណ្តាញឯកជនរបស់ខ្ញុំទេ ព្រោះនៅតែមានហានិភ័យដែលភាគីទីបីអាចគ្រប់គ្រងវាបាន ដូច្នេះហើយការមានឧបករណ៍បែបនេះ នៅលើបណ្តាញផ្ទះរបស់ខ្ញុំគឺមិនចង់បានខ្លាំងណាស់ ហើយវាត្រូវបានសម្រេចចិត្តបង់ប្រាក់សម្រាប់សុវត្ថិភាពជាមួយនឹងការចំណាយលើស។

ដើម្បីបញ្ជូនច្រកនៅលើរ៉ោតទ័រដែលវាត្រូវបានគ្រោងនឹងដាក់ពង្រាយម៉ាស៊ីនមេ កម្មវិធី sshtunnel ត្រូវបានប្រើប្រាស់។ ខ្ញុំនឹងមិនរៀបរាប់ពីភាពស្មុគ្រស្មាញនៃការកំណត់រចនាសម្ព័ន្ធរបស់វានោះទេ - វាត្រូវបានធ្វើយ៉ាងងាយស្រួល ខ្ញុំគ្រាន់តែចំណាំថាភារកិច្ចរបស់វាគឺដើម្បីបញ្ជូនច្រក TCP 1194 ពីរ៉ោតទ័រទៅ VPS ។ បន្ទាប់មក ម៉ាស៊ីនមេ OpenVPN ត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅលើឧបករណ៍ tap0 ដែលត្រូវបានភ្ជាប់ទៅស្ពាន br-lan ។ ដោយបានពិនិត្យការតភ្ជាប់ទៅម៉ាស៊ីនមេដែលទើបបង្កើតថ្មីពីកុំព្យូទ័រយួរដៃ វាច្បាស់ណាស់ថាគំនិតនៃការបញ្ជូនបន្តច្រកគឺមានភាពយុត្តិធម៌ ហើយកុំព្យូទ័រយួរដៃរបស់ខ្ញុំបានក្លាយជាសមាជិកនៃបណ្តាញរ៉ោតទ័រ ទោះបីជាវាមិនមាននៅក្នុងវាក៏ដោយ។

មានរឿងតូចមួយដែលត្រូវធ្វើ៖ វាចាំបាច់ក្នុងការចែកចាយអាសយដ្ឋាន IP នៅក្នុងអាផាតមិនផ្សេងៗគ្នា ដើម្បីកុំឱ្យពួកគេប៉ះទង្គិច និងកំណត់រចនាសម្ព័ន្ធរ៉ោតទ័រជាអតិថិជន OpenVPN ។
អាសយដ្ឋាន IP របស់រ៉ោតទ័រខាងក្រោម និងជួរម៉ាស៊ីនមេ DHCP ត្រូវបានជ្រើសរើស៖

• 192.168.10.1 ជាមួយជួរ 192.168.10.2 - 192.168.10.80 សម្រាប់ម៉ាស៊ីនមេ
• 192.168.10.100 ជាមួយជួរ 192.168.10.101 - 192.168.10.149 សម្រាប់រ៉ោតទ័រនៅក្នុងផ្ទះល្វែងលេខ 2
• 192.168.10.150 ជាមួយជួរ 192.168.10.151 - 192.168.10.199 សម្រាប់រ៉ោតទ័រនៅក្នុងផ្ទះល្វែងលេខ 3

វាក៏ចាំបាច់ផងដែរក្នុងការកំណត់អាសយដ្ឋានទាំងនេះពិតប្រាកដទៅរ៉ោតទ័រម៉ាស៊ីនភ្ញៀវនៃម៉ាស៊ីនមេ OpenVPN ដោយបន្ថែមបន្ទាត់ទៅការកំណត់របស់វា៖

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

ហើយបន្ថែមបន្ទាត់ខាងក្រោមទៅឯកសារ /etc/openvpn/ipp.txt៖

flat1_id 192.168.10.100
flat2_id 192.168.10.150

ដែល flat1_id និង flat2_id គឺជាឈ្មោះឧបករណ៍ដែលបានបញ្ជាក់នៅពេលបង្កើតវិញ្ញាបនបត្រសម្រាប់ភ្ជាប់ទៅ OpenVPN

បន្ទាប់មក អតិថិជន OpenVPN ត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅលើរ៉ោតទ័រ ឧបករណ៍ tap0 នៅលើទាំងពីរត្រូវបានបន្ថែមទៅស្ពាន br-lan ។ នៅដំណាក់កាលនេះ អ្វីៗហាក់បីដូចជាល្អ ព្រោះបណ្តាញទាំងបីអាចមើលឃើញគ្នាទៅវិញទៅមក និងដំណើរការជាតែមួយ។ ទោះជាយ៉ាងណាក៏ដោយ ព័ត៌មានលម្អិតមិនគួរឱ្យរីករាយមួយបានលេចចេញមក៖ ពេលខ្លះឧបករណ៍អាចទទួលបានអាសយដ្ឋាន IP មិនមែនពីរ៉ោតទ័ររបស់ពួកគេ ជាមួយនឹងផលវិបាកដែលកើតឡើងទាំងអស់។ សម្រាប់ហេតុផលមួយចំនួន រ៉ោតទ័រនៅក្នុងអាផាតមិនមួយមិនមានពេលវេលាដើម្បីឆ្លើយតបទៅនឹង DHCPDISCOVER ទាន់ពេលទេ ហើយឧបករណ៍នេះបានទទួលអាសយដ្ឋានដែលមិនមានបំណង។ ខ្ញុំបានដឹងថាខ្ញុំត្រូវត្រងសំណើបែបនេះនៅក្នុង tap0 នៅលើរ៉ោតទ័រនីមួយៗ ប៉ុន្តែដូចដែលវាបានប្រែក្លាយ iptables មិនអាចដំណើរការជាមួយឧបករណ៍បានទេប្រសិនបើវាជាផ្នែកនៃស្ពាន ហើយ ebtables ត្រូវតែមករកជំនួយរបស់ខ្ញុំ។ ជាការសោកស្តាយរបស់ខ្ញុំ វាមិនមាននៅក្នុងកម្មវិធីបង្កប់របស់ខ្ញុំទេ ហើយខ្ញុំត្រូវតែបង្កើតរូបភាពឡើងវិញសម្រាប់ឧបករណ៍នីមួយៗ។ ដោយធ្វើដូចនេះ និងបន្ថែមបន្ទាត់ទាំងនេះទៅ /etc/rc.local នៃរ៉ោតទ័រនីមួយៗ បញ្ហាត្រូវបានដោះស្រាយ៖

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

ការកំណត់នេះមានរយៈពេលបីឆ្នាំ។

ផ្នែកទី 2៖ ការណែនាំ WireGuard

ថ្មីៗនេះ មនុស្សនៅលើអ៊ីនធឺណិតបានចាប់ផ្តើមនិយាយអំពី WireGuard កាន់តែខ្លាំងឡើង ដោយសរសើរពីភាពសាមញ្ញនៃការកំណត់របស់វា ល្បឿនបញ្ជូនខ្ពស់ ភីងទាប ជាមួយនឹងសុវត្ថិភាពដែលអាចប្រៀបធៀបបាន។ ការស្វែងរកព័ត៌មានបន្ថែមអំពីវាបានធ្វើឱ្យវាច្បាស់ថា ទាំងការធ្វើការជាសមាជិកស្ពាន ឬធ្វើការលើពិធីការ TCP ត្រូវបានគាំទ្រដោយវា ដែលធ្វើឱ្យខ្ញុំគិតថានៅតែមិនមានជម្រើសផ្សេងទៀតសម្រាប់ OpenVPN សម្រាប់ខ្ញុំ។ ដូច្នេះខ្ញុំឈប់ស្គាល់ WireGuard ។

ប៉ុន្មានថ្ងៃមុននេះ ព័ត៌មានបានរីករាលដាលពាសពេញធនធានតាមមធ្យោបាយមួយ ឬមធ្យោបាយផ្សេងទៀតទាក់ទងនឹង IT ដែល WireGuard នឹងត្រូវបានបញ្ចូលទៅក្នុងខឺណែលលីនុច ដោយចាប់ផ្តើមជាមួយកំណែ 5.6។ អត្ថបទព័ត៌មានតែងតែសរសើរ WireGuard ។ ខ្ញុំបានធ្លាក់ចូលទៅក្នុងការស្វែងរកវិធីដើម្បីជំនួស OpenVPN ចាស់ដ៏ល្អម្តងទៀត។ លើកនេះខ្ញុំរត់ចូល អត្ថបទនេះ. វានិយាយអំពីការបង្កើតផ្លូវរូងក្រោមដីអ៊ីសឺរណិតលើ L3 ដោយប្រើ GRE ។ អត្ថបទនេះបានផ្តល់ក្តីសង្ឃឹមដល់ខ្ញុំ។ វានៅតែមិនច្បាស់ថាតើត្រូវធ្វើអ្វីជាមួយពិធីការ UDP ។ ការស្វែងរកបាននាំខ្ញុំទៅអត្ថបទអំពីការប្រើ socat ក្នុងការភ្ជាប់ជាមួយផ្លូវរូងក្រោមដី SSH ដើម្បីបញ្ជូនបន្តច្រក UDP ទោះបីជាយ៉ាងណាក៏ដោយ ពួកគេបានកត់សម្គាល់ថាវិធីសាស្រ្តនេះដំណើរការតែក្នុងរបៀបតភ្ជាប់តែមួយប៉ុណ្ណោះ ពោលគឺការងាររបស់ម៉ាស៊ីនភ្ញៀវ VPN ជាច្រើននឹងមិនអាចទៅរួចទេ។ ខ្ញុំបានបង្កើតឡើងនូវគំនិតនៃការដំឡើងម៉ាស៊ីនមេ VPN នៅលើ VPS និងដំឡើង GRE សម្រាប់អតិថិជន ប៉ុន្តែដូចដែលវាបានប្រែក្លាយ GRE មិនគាំទ្រការអ៊ិនគ្រីបដែលនឹងនាំឱ្យការពិតដែលថាប្រសិនបើភាគីទីបីទទួលបានសិទ្ធិចូលប្រើម៉ាស៊ីនមេ។ ចរាចរណ៍ទាំងអស់រវាងបណ្តាញរបស់ខ្ញុំនឹងស្ថិតនៅក្នុងដៃរបស់ពួកគេ ដែលមិនសមនឹងខ្ញុំទាល់តែសោះ។

ជា​ថ្មី​ម្តង​ទៀត ការ​សម្រេច​ចិត្ត​ត្រូវ​បាន​ធ្វើ​ឡើង​ក្នុង​ការ​គាំទ្រ​ដល់​ការ​អ៊ិនគ្រីប​ដែល​មិន​ប្រើ​ប្រាស់​ដោយ​ប្រើ VPN លើ VPN ដោយ​ប្រើ​គ្រោងការណ៍​ដូច​ខាង​ក្រោម៖

កម្រិត XNUMX VPN៖
ការ VPS វាគឺជាការ ម៉ាស៊ីនមេ ជាមួយអាសយដ្ឋានខាងក្នុង 192.168.30.1
អេស វាគឺជាការ អតិថិជន VPS ដែលមានអាសយដ្ឋានខាងក្នុង 192.168.30.2
MK2 វាគឺជាការ អតិថិជន VPS ដែលមានអាសយដ្ឋានខាងក្នុង 192.168.30.3
MK3 វាគឺជាការ អតិថិជន VPS ដែលមានអាសយដ្ឋានខាងក្នុង 192.168.30.4

VPN កម្រិតទីពីរ៖
អេស វាគឺជាការ ម៉ាស៊ីនមេ ជាមួយអាសយដ្ឋានខាងក្រៅ 192.168.30.2 និងខាងក្នុង 192.168.31.1
MK2 វាគឺជាការ អតិថិជន អេស ជាមួយអាសយដ្ឋាន 192.168.30.2 និងមាន IP ខាងក្នុង 192.168.31.2
MK3 វាគឺជាការ អតិថិជន អេស ជាមួយអាសយដ្ឋាន 192.168.30.2 និងមាន IP ខាងក្នុង 192.168.31.3

* អេស - ម៉ាស៊ីនមេរ៉ោតទ័រនៅក្នុងផ្ទះល្វែង 1, MK2 - រ៉ោតទ័រនៅក្នុងផ្ទះល្វែង 2, MK3 -រ៉ោតទ័រក្នុងផ្ទះល្វែង ៣
* ការកំណត់រចនាសម្ព័ន្ធឧបករណ៍ត្រូវបានបោះពុម្ពផ្សាយនៅក្នុង spoiler នៅចុងបញ្ចប់នៃអត្ថបទ។

ដូច្នេះហើយ ភីងកំពុងដំណើរការរវាងថ្នាំងបណ្តាញ 192.168.31.0/24 វាដល់ពេលដែលត្រូវបន្តទៅការដំឡើងផ្លូវរូងក្រោមដី GRE ។ មុននេះ ដើម្បីកុំឱ្យបាត់បង់ការចូលប្រើរ៉ោតទ័រ វាមានតម្លៃរៀបចំផ្លូវរូងក្រោមដី SSH ដើម្បីបញ្ជូនច្រក 22 ទៅ VPS ដូច្នេះឧទាហរណ៍ រ៉ោតទ័រពីអាផាតមិន 10022 នឹងអាចចូលប្រើបាននៅលើច្រក 2 នៃ VPS ហើយ រ៉ោតទ័រពីអាផាតមិន 11122 នឹងអាចចូលប្រើបាននៅលើច្រក 3 រ៉ោតទ័រពីអាផាតមិន XNUMX។ វាជាការល្អបំផុតក្នុងការកំណត់ការបញ្ជូនបន្តដោយប្រើ sshtunnel ដូចគ្នា ព្រោះវានឹងស្ដារផ្លូវរូងក្រោមដីប្រសិនបើវាបរាជ័យ។

ផ្លូវរូងក្រោមដីត្រូវបានកំណត់រចនាសម្ព័ន្ធ អ្នកអាចភ្ជាប់ទៅ SSH តាមរយៈច្រកបញ្ជូនបន្ត៖

ssh root@МОЙ_VPS -p 10022

បន្ទាប់អ្នកគួរតែបិទ OpenVPN៖

/etc/init.d/openvpn stop

ឥឡូវនេះសូមរៀបចំផ្លូវរូងក្រោមដី GRE នៅលើរ៉ោតទ័រពីអាផាតមិន 2៖

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

ហើយបន្ថែមចំណុចប្រទាក់ដែលបានបង្កើតទៅស្ពាន៖

brctl addif br-lan grelan0

តោះអនុវត្តនីតិវិធីស្រដៀងគ្នានៅលើរ៉ោតទ័រម៉ាស៊ីនមេ៖

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

ហើយបន្ថែមចំណុចប្រទាក់ដែលបានបង្កើតទៅស្ពាន៖

brctl addif br-lan grelan0

ចាប់​ពី​ពេល​នេះ ភីង​ចាប់​ផ្ដើម​ចូល​បណ្តាញ​ថ្មី​ដោយ​ជោគជ័យ ហើយ​ខ្ញុំ​ទៅ​ផឹក​កាហ្វេ​ដោយ​ក្ដី​ពេញ​ចិត្ត។ បន្ទាប់មក ដើម្បីវាយតម្លៃពីរបៀបដែលបណ្តាញកំពុងដំណើរការនៅផ្នែកម្ខាងទៀតនៃបន្ទាត់ ខ្ញុំព្យាយាមបញ្ចូល SSH ទៅក្នុងកុំព្យូទ័រមួយក្នុងចំណោមកុំព្យូទ័រក្នុងអាផាតមិន 2 ប៉ុន្តែម៉ាស៊ីនភ្ញៀវ ssh បង្កកដោយមិនទាមទារពាក្យសម្ងាត់ទេ។ ខ្ញុំកំពុងព្យាយាមភ្ជាប់ទៅកុំព្យូទ័រនេះតាមរយៈ telnet នៅលើច្រក 22 ហើយខ្ញុំឃើញបន្ទាត់ដែលខ្ញុំអាចយល់បានថាការតភ្ជាប់កំពុងត្រូវបានបង្កើតឡើង នោះម៉ាស៊ីនមេ SSH កំពុងឆ្លើយតប ប៉ុន្តែសម្រាប់ហេតុផលមួយចំនួនវាគ្រាន់តែមិនជំរុញឱ្យខ្ញុំចូល។ ក្នុង

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

ខ្ញុំកំពុងព្យាយាមភ្ជាប់វាតាមរយៈ VNC ហើយឃើញអេក្រង់ខ្មៅ។ ខ្ញុំបញ្ចុះបញ្ចូលខ្លួនឯងថាបញ្ហាគឺជាមួយកុំព្យូទ័រពីចម្ងាយព្រោះខ្ញុំអាចភ្ជាប់រ៉ោតទ័របានយ៉ាងងាយស្រួលពីអាផាតមិននេះដោយប្រើអាសយដ្ឋានខាងក្នុង។ ទោះយ៉ាងណាក៏ដោយ ខ្ញុំសម្រេចចិត្តភ្ជាប់ទៅ SSH នៃកុំព្យូទ័រនេះតាមរយៈរ៉ោតទ័រ ហើយខ្ញុំភ្ញាក់ផ្អើលដែលដឹងថាការតភ្ជាប់បានជោគជ័យ ហើយកុំព្យូទ័រពីចម្ងាយដំណើរការជាធម្មតា ប៉ុន្តែវាក៏មិនអាចភ្ជាប់ទៅកុំព្យូទ័ររបស់ខ្ញុំដែរ។

ខ្ញុំដកឧបករណ៍ grelan0 ចេញពីស្ពាន ហើយដំណើរការ OpenVPN នៅលើរ៉ោតទ័រក្នុងអាផាតមិន 2 ហើយត្រូវប្រាកដថាបណ្តាញដំណើរការដូចការរំពឹងទុកម្តងទៀត ហើយការតភ្ជាប់មិនត្រូវបានទម្លាក់ទេ។ តាមរយៈការស្វែងរក ខ្ញុំបានឆ្លងកាត់វេទិកាដែលមនុស្សត្អូញត្អែរអំពីបញ្ហាដូចគ្នា ដែលពួកគេត្រូវបានណែនាំឱ្យលើកឡើង MTU ។ មិនមែននិយាយលឿនជាងធ្វើទេ។ ទោះយ៉ាងណាក៏ដោយរហូតដល់ MTU ត្រូវបានកំណត់ខ្ពស់គ្រប់គ្រាន់ - 7000 សម្រាប់ឧបករណ៍ Gretap ទាំងការភ្ជាប់ TCP ដែលបានធ្លាក់ចុះ ឬអត្រាផ្ទេរទិន្នន័យទាបត្រូវបានគេសង្កេតឃើញ។ ដោយសារ MTU ខ្ពស់សម្រាប់ gretap MTUs សម្រាប់ Layer 8000 និង Layer 7500 ការតភ្ជាប់ WireGuard ត្រូវបានកំណត់ទៅ XNUMX និង XNUMX រៀងគ្នា។

ខ្ញុំបានអនុវត្តការដំឡើងស្រដៀងគ្នានៅលើរ៉ោតទ័រពីអាផាតមិន 3 ជាមួយនឹងភាពខុសគ្នាតែមួយគត់គឺថាចំណុចប្រទាក់ Gretap ទីពីរដែលមានឈ្មោះថា grelan1 ត្រូវបានបន្ថែមទៅរ៉ោតទ័រម៉ាស៊ីនមេ ដែលត្រូវបានបន្ថែមទៅស្ពាន br-lan ផងដែរ។

អ្វីគ្រប់យ៉ាងកំពុងដំណើរការ។ ឥឡូវ​នេះ​អ្នក​អាច​ដាក់​ការ​ជួប​ប្រជុំ Gretap ទៅ​ក្នុង​ការ​ចាប់​ផ្តើ​ម​។ សម្រាប់​ការ​នេះ:

ខ្ញុំបានដាក់បន្ទាត់ទាំងនេះនៅក្នុង /etc/rc.local នៅលើរ៉ោតទ័រក្នុងអាផាតមិន 2៖

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

បានបន្ថែមវាទៅ /etc/rc.local នៅលើរ៉ោតទ័រក្នុងអាផាតមិន 3៖

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ហើយនៅលើ server router៖

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1

បន្ទាប់ពីបើកដំណើរការរ៉ោតទ័រម៉ាស៊ីនភ្ញៀវឡើងវិញ ខ្ញុំបានរកឃើញថាសម្រាប់ហេតុផលមួយចំនួនដែលពួកគេមិនភ្ជាប់ទៅម៉ាស៊ីនមេ។ ដោយបានភ្ជាប់ទៅ SSH របស់ពួកគេ (ជាសំណាងល្អ ខ្ញុំបានកំណត់រចនាសម្ព័ន្ធ sshtunnel ពីមុនសម្រាប់វា) វាត្រូវបានគេរកឃើញថា WireGuard សម្រាប់ហេតុផលមួយចំនួនកំពុងបង្កើតផ្លូវសម្រាប់ចំណុចបញ្ចប់ ប៉ុន្តែវាមិនត្រឹមត្រូវទេ។ ដូច្នេះសម្រាប់ 192.168.30.2 តារាងផ្លូវបានចង្អុលបង្ហាញផ្លូវមួយតាមរយៈចំណុចប្រទាក់ pppoe-wan ពោលគឺតាមរយៈអ៊ីនធឺណិត ទោះបីជាផ្លូវទៅកាន់វាគួរតែត្រូវបានបញ្ជូនតាមរយៈចំណុចប្រទាក់ wg0 ក៏ដោយ។ បន្ទាប់ពីលុបផ្លូវនេះ ការតភ្ជាប់ត្រូវបានស្ដារឡើងវិញ។ ខ្ញុំមិនអាចស្វែងរកការណែនាំគ្រប់ទីកន្លែងអំពីរបៀបបង្ខំ WireGuard មិនឱ្យបង្កើតផ្លូវទាំងនេះទេ។ ជាងនេះទៅទៀត ខ្ញុំមិនយល់ថាតើនេះជាលក្ខណៈរបស់ OpenWRT ឬ WireGuard ខ្លួនឯងទេ។ ដោយមិនចាំបាច់ដោះស្រាយបញ្ហានេះយូរទេ ខ្ញុំគ្រាន់តែបន្ថែមបន្ទាត់មួយទៅរ៉ោតទ័រទាំងពីរនៅក្នុងស្គ្រីបកំណត់ពេលដែលបានលុបផ្លូវនេះ៖

route del 192.168.30.2

សង្ខេប

ខ្ញុំមិនទាន់សម្រេចបាននូវការបោះបង់ចោលទាំងស្រុងនៃ OpenVPN ទេ ព្រោះពេលខ្លះខ្ញុំត្រូវភ្ជាប់ទៅបណ្តាញថ្មីពីកុំព្យូទ័រយួរដៃ ឬទូរស័ព្ទ ហើយការដំឡើងឧបករណ៍ Gretap នៅលើពួកវាជាទូទៅមិនអាចទៅរួចទេ ប៉ុន្តែទោះបីជានេះក៏ដោយ ខ្ញុំទទួលបានអត្ថប្រយោជន៍មួយក្នុងល្បឿន ការផ្ទេរទិន្នន័យរវាងអាផាតមិន ហើយឧទាហរណ៍ការប្រើ VNC លែងមានការរអាក់រអួលទៀតហើយ។ Ping ថយចុះបន្តិច ប៉ុន្តែមានស្ថេរភាពជាងមុន៖

នៅពេលប្រើ OpenVPN៖

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

នៅពេលប្រើ WireGuard៖

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

វាត្រូវបានរងផលប៉ះពាល់កាន់តែច្រើនដោយ ping ខ្ពស់ទៅ VPS ដែលមានប្រហែល 61.5 ms

ទោះជាយ៉ាងណាក៏ដោយល្បឿនបានកើនឡើងយ៉ាងខ្លាំង។ ដូច្នេះនៅក្នុងអាផាតមិនដែលមានរ៉ោតទ័រម៉ាស៊ីនមេ ខ្ញុំមានល្បឿនភ្ជាប់អ៊ីនធឺណិត 30 Mbit/s ហើយនៅក្នុងផ្ទះល្វែងផ្សេងទៀតវាមាន 5 Mbit/sec។ ក្នុងពេលជាមួយគ្នានេះ ខណៈពេលកំពុងប្រើ OpenVPN ខ្ញុំមិនអាចសម្រេចបាននូវល្បឿនផ្ទេរទិន្នន័យរវាងបណ្តាញលើសពី 3,8 Mbit/s បើយោងតាមការអាន iperf ខណៈពេលដែល WireGuard "បង្កើន" វាទៅដូចគ្នា 5 Mbit/sec ។

ការកំណត់រចនាសម្ព័ន្ធ WireGuard នៅលើ VPS[Interface] Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
AllowedIPs = 192.168.30.2/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
AllowedIPs = 192.168.30.3/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
AllowedIPs = 192.168.30.4/32

ការកំណត់រចនាសម្ព័ន្ធ WireGuard នៅលើ MS (បន្ថែមទៅ /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3

        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

ការកំណត់រចនាសម្ព័ន្ធ WireGuard នៅលើ MK2 (បន្ថែមទៅ /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

ការកំណត់រចនាសម្ព័ន្ធ WireGuard នៅលើ MK3 (បន្ថែមទៅ /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

នៅក្នុងការកំណត់ដែលបានពិពណ៌នាសម្រាប់ VPN កម្រិតទីពីរ ខ្ញុំចង្អុលទៅម៉ាស៊ីនភ្ញៀវ WireGuard ទៅកាន់ច្រក 51821។ តាមទ្រឹស្តី វាមិនចាំបាច់ទេ ដោយសារអតិថិជននឹងបង្កើតការតភ្ជាប់ពីច្រកដែលមិនមានការអនុញ្ញាតដោយឥតគិតថ្លៃ ប៉ុន្តែខ្ញុំបានធ្វើវាដើម្បីឱ្យវាអាចហាមឃាត់បាន។ ការភ្ជាប់ចូលទាំងអស់នៅលើចំណុចប្រទាក់ wg0 នៃរ៉ោតទ័រទាំងអស់ លើកលែងតែការភ្ជាប់ UDP ចូលទៅកាន់ច្រក 51821។

ខ្ញុំសង្ឃឹមថាអត្ថបទនឹងមានប្រយោជន៍សម្រាប់នរណាម្នាក់។

PS ដូចគ្នានេះផងដែរខ្ញុំចង់ចែករំលែកស្គ្រីបរបស់ខ្ញុំដែលផ្ញើការជូនដំណឹង PUSH មកទូរស័ព្ទរបស់ខ្ញុំនៅក្នុងកម្មវិធី WirePusher នៅពេលដែលឧបករណ៍ថ្មីលេចឡើងនៅលើបណ្តាញរបស់ខ្ញុំ។ នេះជាតំណភ្ជាប់ទៅស្គ្រីប៖ github.com/r0ck3r/device_discover.

ធ្វើឱ្យទាន់សម័យ: ការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ OpenVPN និងអតិថិជន

ម៉ាស៊ីនមេ OpenVPN

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

ម៉ាស៊ីនភ្ញៀវ OpenVPN

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

ខ្ញុំបានប្រើ easy-rsa ដើម្បីបង្កើតវិញ្ញាបនបត្រ

ប្រភព: www.habr.com