බොහෝ කලකට පෙර 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) ලිපිනය ඕනෑම නෝඩ් අතුරුමුහුණතකට අමුණා ඇත (උදාහරණයක් ලෙස 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 අතුරුමුහුණතක් සෑදිය යුතුය:

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: ඔබට ප්‍රතිපත්ති මත පදනම් වූ මාර්ගගත කිරීම අවශ්‍ය වූ විට

ජාල ස්ථලකය පෙර උදාහරණයේ සමාන වේ, නමුත් ඔබට බාහිර සංචිත ලිපින වෙත ප්‍රවේශ වීමට අවශ්‍ය යැයි සිතමු. 1.2.3.0/24 ඔබේ කරල් වලින්:

විශේෂත්වය වන්නේ ඕනෑම ලිපිනයකට පිවිසීමේදීය 1.2.3.0/24, ප්‍රතිචාර පැකට්ටුව නෝඩයට පහර දෙන අතර පරාසයේ මූලාශ්‍ර ලිපිනයක් ඇත 1.2.3.0/24 වෙත කීකරු ලෙස යවනු ලැබේ eth0.100, නමුත් අපට Kubernetes එය මුල් ඉල්ලීම ජනනය කළ අපගේ පළමු පොඩ් වෙත හරවා යැවීමට අවශ්‍යය.

මෙම ගැටළුව විසඳීම දුෂ්කර විය, නමුත් ප්‍රතිපත්ති මත පදනම් වූ මාර්ගගත කිරීම නිසා එය කළ හැකි විය:

ක්‍රියාවලිය පිළිබඳ වඩා හොඳ අවබෝධයක් සඳහා, මෙන්න netfilter block සටහනක්:

පළමුව, පෙර උදාහරණයේ දී මෙන්, අපි අතිරේක මාර්ගගත වගුවක් නිර්මාණය කරමු:

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 සක්‍රීයව පවතිනු ඇත.

ෆිල්ටරයේ ක්‍රියාකාරිත්වය සම්පූර්ණයෙන්ම සීමා නොකිරීමට, අපට netfilter සඳහා rp_filter ක්‍රියාත්මක කිරීම භාවිතා කළ හැක. 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