មិនយូរប៉ុន្មានទេ ខ្ញុំបានប្រឈមមុខនឹងការងារមិនធម្មតាមួយក្នុងការដំឡើង routing សម្រាប់ MetalLB។ អ្វីៗនឹងល្អ ព្រោះ... ជាធម្មតា MetalLB មិនតម្រូវឱ្យមានសកម្មភាពបន្ថែមទេ ប៉ុន្តែក្នុងករណីរបស់យើង យើងមានចង្កោមធំល្មមជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធបណ្តាញដ៏សាមញ្ញបំផុត។

នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងប្រាប់អ្នកពីរបៀបកំណត់រចនាសម្ព័ន្ធផ្លូវផ្អែកលើប្រភព និងគោលការណ៍ផ្អែកលើបណ្តាញសម្រាប់បណ្តាញខាងក្រៅនៃចង្កោមរបស់អ្នក។

ខ្ញុំនឹងមិននិយាយលម្អិតអំពីការដំឡើង និងកំណត់រចនាសម្ព័ន្ធ MetalLB ទេ ព្រោះខ្ញុំសន្មត់ថាអ្នកមានបទពិសោធន៍ខ្លះហើយ។ ខ្ញុំស្នើឱ្យទៅត្រង់ចំណុច ពោលគឺការកំណត់ផ្លូវ។ ដូច្នេះយើងមានបួនករណី៖

ករណីទី 1: នៅពេលដែលមិនមានការកំណត់រចនាសម្ព័ន្ធត្រូវបានទាមទារ

សូមក្រឡេកមើលករណីសាមញ្ញមួយ។

ការកំណត់រចនាសម្ព័ន្ធផ្លូវបន្ថែមមិនត្រូវបានទាមទារទេ នៅពេលដែលអាសយដ្ឋានដែលចេញដោយ MetalLB ស្ថិតនៅក្នុងបណ្តាញរងដូចគ្នាជាមួយនឹងអាសយដ្ឋាននៃថ្នាំងរបស់អ្នក។

ឧទាហរណ៍ អ្នកមានបណ្តាញរង 192.168.1.0/24វាមានរ៉ោតទ័រ 192.168.1.1ហើយថ្នាំងរបស់អ្នកទទួលបានអាសយដ្ឋាន៖ 192.168.1.10-30បន្ទាប់មកសម្រាប់ MetalLB អ្នកអាចលៃតម្រូវជួរបាន។ 192.168.1.100-120 ហើយត្រូវប្រាកដថាពួកគេនឹងដំណើរការដោយគ្មានការកំណត់បន្ថែមណាមួយឡើយ។

ហេតុអ្វីបានជា​អញ្ចឹង? ដោយសារតែថ្នាំងរបស់អ្នកបានកំណត់រចនាសម្ព័ន្ធផ្លូវរួចហើយ៖

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

ហើយអាសយដ្ឋានពីជួរដូចគ្នានឹងប្រើពួកវាឡើងវិញដោយគ្មានសកម្មភាពបន្ថែមណាមួយឡើយ។

ករណីទី 2: នៅពេលដែលការប្ដូរតាមបំណងបន្ថែមត្រូវបានទាមទារ

អ្នកគួរតែកំណត់រចនាសម្ព័ន្ធផ្លូវបន្ថែមនៅពេលណាដែលថ្នាំងរបស់អ្នកមិនមានអាសយដ្ឋាន IP ដែលបានកំណត់រចនាសម្ព័ន្ធ ឬផ្លូវទៅកាន់បណ្តាញរងដែល MetalLB ចេញអាសយដ្ឋាន។

ខ្ញុំនឹងពន្យល់លម្អិតបន្តិចទៀត។ នៅពេលណាដែល MetalLB បញ្ចេញអាសយដ្ឋាន វាអាចប្រៀបធៀបទៅនឹងកិច្ចការសាមញ្ញដូចជា៖

ip addr add 10.9.8.7/32 dev lo

យកចិត្តទុកដាក់ចំពោះ៖

• a) អាសយដ្ឋាន​ត្រូវ​បាន​កំណត់​ដោយ​បុព្វបទ /32 នោះគឺផ្លូវមួយនឹងមិនត្រូវបានបន្ថែមដោយស្វ័យប្រវត្តិទៅបណ្តាញរងសម្រាប់វាទេ (វាគ្រាន់តែជាអាសយដ្ឋាន)
• b) អាសយដ្ឋានត្រូវបានភ្ជាប់ទៅចំណុចប្រទាក់ node ណាមួយ (ឧទាហរណ៍ loopback)។ វាគឺមានតំលៃនិយាយនៅទីនេះអំពីលក្ខណៈពិសេសនៃជង់បណ្តាញលីនុច។ មិនថាចំណុចប្រទាក់ណាមួយដែលអ្នកបន្ថែមអាសយដ្ឋានទៅ ខឺណែលនឹងដំណើរការសំណើ arp ជានិច្ច ហើយផ្ញើការឆ្លើយតប arp ទៅកាន់ពួកវាណាមួយ ឥរិយាបថនេះត្រូវបានចាត់ទុកថាត្រឹមត្រូវ ហើយលើសពីនេះទៅទៀត ត្រូវបានគេប្រើយ៉ាងទូលំទូលាយនៅក្នុងបរិយាកាសថាមវន្តដូចជា Kubernetes ។

ឥរិយាបថនេះអាចត្រូវបានប្ដូរតាមបំណង ឧទាហរណ៍ដោយបើក arp តឹងរឹង៖

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

ក្នុងករណីនេះ ការឆ្លើយតប arp នឹងត្រូវបានផ្ញើលុះត្រាតែចំណុចប្រទាក់មានអាសយដ្ឋាន IP ជាក់លាក់ជាក់លាក់មួយ។ ការកំណត់នេះត្រូវបានទាមទារ ប្រសិនបើអ្នកមានគម្រោងប្រើ MetalLB ហើយ kube-proxy របស់អ្នកកំពុងដំណើរការក្នុងរបៀប IPVS។

ទោះយ៉ាងណាក៏ដោយ MetalLB មិនប្រើខឺណែលដើម្បីដំណើរការសំណើ arp ទេ ប៉ុន្តែធ្វើវាដោយខ្លួនវាផ្ទាល់ក្នុងចន្លោះអ្នកប្រើប្រាស់ ដូច្នេះជម្រើសនេះនឹងមិនប៉ះពាល់ដល់ប្រតិបត្តិការរបស់ MetalLB ទេ។

ចូរយើងត្រលប់ទៅភារកិច្ចរបស់យើង។ ប្រសិនបើផ្លូវសម្រាប់អាសយដ្ឋានដែលបានចេញមិនមាននៅលើថ្នាំងរបស់អ្នកទេ សូមបន្ថែមវាជាមុនទៅកាន់ថ្នាំងទាំងអស់៖

ip route add 10.9.8.0/24 dev eth1

ករណីទី 3: នៅពេលដែលអ្នកត្រូវការការបញ្ជូនតាមប្រភព

អ្នកនឹងត្រូវកំណត់រចនាសម្ព័ន្ធការបញ្ជូនតាមប្រភព នៅពេលអ្នកទទួលកញ្ចប់ព័ត៌មានតាមរយៈច្រកផ្លូវដាច់ដោយឡែក មិនមែនជាការកំណត់រចនាសម្ព័ន្ធតាមលំនាំដើមទេ ដូច្នេះកញ្ចប់ឆ្លើយតបក៏គួរតែឆ្លងកាត់ច្រកទ្វារដូចគ្នាដែរ។

ឧទាហរណ៍ អ្នកមានបណ្តាញរងដូចគ្នា។ 192.168.1.0/24 ឧទ្ទិសដល់ថ្នាំងរបស់អ្នក ប៉ុន្តែអ្នកចង់ចេញអាសយដ្ឋានខាងក្រៅដោយប្រើ MetalLB ។ ចូរសន្មតថាអ្នកមានអាសយដ្ឋានច្រើនពីបណ្តាញរង 1.2.3.0/24 ដែលមានទីតាំងនៅ VLAN 100 ហើយអ្នកចង់ប្រើពួកវាដើម្បីចូលប្រើសេវាកម្ម Kubernetes ខាងក្រៅ។

នៅពេលទាក់ទង 1.2.3.4 អ្នកនឹងធ្វើការស្នើសុំពីបណ្តាញរងផ្សេងពី 1.2.3.0/24 ហើយរង់ចាំចម្លើយ។ ថ្នាំងដែលបច្ចុប្បន្នជាមេសម្រាប់អាសយដ្ឋានដែលចេញដោយ MetalLB 1.2.3.4នឹងទទួលបានកញ្ចប់ព័ត៌មានពីរ៉ោតទ័រ 1.2.3.1ប៉ុន្តែចម្លើយសម្រាប់គាត់ត្រូវតែទៅផ្លូវដូចគ្នា ឆ្លងកាត់ 1.2.3.1.

ដោយសារថ្នាំងរបស់យើងមានច្រកផ្លូវលំនាំដើមដែលបានកំណត់រចនាសម្ព័ន្ធរួចហើយ 192.168.1.1បន្ទាប់មកតាមលំនាំដើម ការឆ្លើយតបនឹងទៅគាត់ និងមិនទៅ 1.2.3.1តាមរយៈការដែលយើងបានទទួលកញ្ចប់។

តើធ្វើដូចម្តេចដើម្បីទប់ទល់នឹងស្ថានភាពនេះ?

ក្នុងករណីនេះ អ្នកត្រូវរៀបចំថ្នាំងរបស់អ្នកទាំងអស់តាមរបៀបដែលពួកវាត្រៀមរួចរាល់ដើម្បីបម្រើអាសយដ្ឋានខាងក្រៅដោយមិនមានការកំណត់បន្ថែម។ នោះគឺសម្រាប់ឧទាហរណ៍ខាងលើ អ្នកត្រូវបង្កើតចំណុចប្រទាក់ VLAN នៅលើ node ជាមុន៖

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

ហើយបន្ទាប់មកបន្ថែមផ្លូវ៖

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

សូមចំណាំថាយើងបន្ថែមផ្លូវទៅកាន់តារាងនាំផ្លូវដាច់ដោយឡែក 100 វានឹងមានផ្លូវពីរប៉ុណ្ណោះដែលចាំបាច់ដើម្បីផ្ញើកញ្ចប់ឆ្លើយតបតាមរយៈច្រកផ្លូវ 1.2.3.1ដែលមានទីតាំងនៅខាងក្រោយចំណុចប្រទាក់ eth0.100.

ឥឡូវយើងត្រូវបន្ថែមច្បាប់សាមញ្ញ៖

ip rule add from 1.2.3.0/24 lookup 100

ដែលនិយាយយ៉ាងច្បាស់៖ ប្រសិនបើអាសយដ្ឋានប្រភពរបស់កញ្ចប់ព័ត៌មានគឺនៅក្នុង 1.2.3.0/24បន្ទាប់មកអ្នកត្រូវប្រើតារាងនាំផ្លូវ 100. ក្នុង​នោះ​យើង​បាន​រៀប​រាប់​រួច​ហើយ​នូវ​ផ្លូវ​ដែល​នឹង​បញ្ជូន​គាត់​ទៅ​តាម 1.2.3.1

ករណីទី 4: នៅពេលដែលអ្នកត្រូវការការកំណត់ផ្លូវដោយផ្អែកលើគោលការណ៍

បណ្តាញ topology គឺដូចគ្នានឹងឧទាហរណ៍ពីមុនដែរ ប៉ុន្តែសូមនិយាយថាអ្នកក៏ចង់អាចចូលប្រើអាសយដ្ឋានអាងខាងក្រៅបានដែរ 1.2.3.0/24 ពីផតថលរបស់អ្នក៖

ភាពពិសេសនោះគឺថានៅពេលដែលចូលទៅកាន់អាសយដ្ឋានណាមួយនៅក្នុង 1.2.3.0/24កញ្ចប់ឆ្លើយតបប៉ះថ្នាំង និងមានអាសយដ្ឋានប្រភពនៅក្នុងជួរ 1.2.3.0/24 នឹងត្រូវបានផ្ញើដោយគោរពតាម eth0.100ប៉ុន្តែយើងចង់ឱ្យ Kubernetes ប្តូរទិសវាទៅផតដំបូងរបស់យើង ដែលបង្កើតសំណើដើម។

ការដោះស្រាយបញ្ហានេះបានក្លាយទៅជាការពិបាក ប៉ុន្តែវាអាចទៅរួច ដោយសារការកំណត់ផ្លូវផ្អែកលើគោលការណ៍៖

សម្រាប់ការយល់ដឹងកាន់តែច្បាស់អំពីដំណើរការនេះគឺជាដ្យាក្រាមប្លុក netfilter៖

ជាដំបូង ដូចក្នុងឧទាហរណ៍មុន តោះបង្កើតតារាងនាំផ្លូវបន្ថែម៖

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

ឥឡូវនេះសូមបន្ថែមច្បាប់មួយចំនួនទៅ iptables៖

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

ច្បាប់ទាំងនេះនឹងសម្គាល់ការតភ្ជាប់ចូលទៅកាន់ចំណុចប្រទាក់ eth0.100សម្គាល់កញ្ចប់ព័ត៌មានទាំងអស់ដោយស្លាក 0x100ការឆ្លើយតបនៅក្នុងការតភ្ជាប់ដូចគ្នាក៏នឹងត្រូវបានសម្គាល់ដោយស្លាកដូចគ្នាដែរ។

ឥឡូវ​នេះ យើង​អាច​បន្ថែម​ច្បាប់​កំណត់​ផ្លូវ៖

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

នោះគឺកញ្ចប់ទាំងអស់ដែលមានអាសយដ្ឋានប្រភព 1.2.3.0/24 និងស្លាក 0x100 ត្រូវតែដំណើរការដោយប្រើតារាង 100.

ដូច្នេះ កញ្ចប់ព័ត៌មានផ្សេងទៀតដែលទទួលបាននៅលើចំណុចប្រទាក់ផ្សេងទៀតមិនស្ថិតក្រោមច្បាប់នេះទេ ដែលនឹងអនុញ្ញាតឱ្យពួកវាត្រូវបានបញ្ជូនដោយប្រើឧបករណ៍ Kubernetes ស្តង់ដារ។

មានរឿងមួយបន្ថែមទៀត នៅក្នុងលីនុច មានអ្វីដែលគេហៅថា តម្រងផ្លូវបញ្ច្រាស ដែលបំផ្លាញអ្វីៗទាំងអស់ វាដំណើរការការត្រួតពិនិត្យសាមញ្ញ៖ សម្រាប់កញ្ចប់ព័ត៌មានចូលទាំងអស់ វាផ្លាស់ប្តូរអាសយដ្ឋានប្រភពនៃកញ្ចប់ព័ត៌មានជាមួយអាសយដ្ឋានអ្នកផ្ញើ និងពិនិត្យមើលថាតើ កញ្ចប់ព័ត៌មានអាចទុកតាមរយៈចំណុចប្រទាក់ដូចគ្នាដែលវាត្រូវបានទទួល បើមិនដូច្នោះទេ វានឹងត្រងវាចេញ។

បញ្ហាគឺថាក្នុងករណីរបស់យើងវានឹងមិនដំណើរការត្រឹមត្រូវទេ ប៉ុន្តែយើងអាចបិទវាបាន៖

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

សូមចំណាំថាពាក្យបញ្ជាទីមួយគ្រប់គ្រងឥរិយាបទសកលរបស់ rp_filter ប្រសិនបើវាមិនត្រូវបានបិទទេ ពាក្យបញ្ជាទីពីរនឹងមិនមានឥទ្ធិពលទេ។ ទោះយ៉ាងណាក៏ដោយ ចំណុចប្រទាក់ដែលនៅសល់នឹងនៅតែមានជាមួយ rp_filter ត្រូវបានបើក។

ដើម្បីមិនកំណត់ប្រតិបត្តិការរបស់តម្រងទាំងស្រុង យើងអាចប្រើការអនុវត្ត rp_filter សម្រាប់ netfilter ។ ដោយប្រើ rpfilter ជាម៉ូឌុល iptables អ្នកអាចកំណត់រចនាសម្ព័ន្ធច្បាប់ដែលអាចបត់បែនបាន ឧទាហរណ៍៖

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

បើក rp_filter នៅលើចំណុចប្រទាក់ eth0.100 សម្រាប់អាសយដ្ឋានទាំងអស់លើកលែងតែ 1.2.3.0/24.

ប្រភព: www.habr.com