ډیر وخت دمخه زه د 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) پته د هر نوډ انٹرفیس سره وصل دی (د مثال په توګه لوپ بیک). دلته د یادولو وړ ده چې د لینکس شبکې سټیک ځانګړتیاوې. مهمه نده چې تاسو په کوم انٹرفیس کې پته اضافه کړئ ، کرنل به تل د arp غوښتنې پروسس کوي او هر یو ته د arp ځوابونه لیږي ، دا چلند سم ګڼل کیږي او سربیره پردې ، په پراخه کچه په داسې متحرک چاپیریال کې لکه کوبرنیټس کې کارول کیږي.

دا چلند دودیز کیدی شي، د بیلګې په توګه د سخت آر پی فعالولو سره:

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

په دې حالت کې، د arp ځوابونه به یوازې واستول شي که چیرې انٹرفیس په واضح ډول یو ځانګړی IP پته ولري. دا ترتیب اړین دی که تاسو د MetalLB کارولو پلان لرئ او ستاسو کیوب پراکسي په IPVS حالت کې روان وي.

په هرصورت، MetalLB د arp غوښتنو پروسس کولو لپاره کرنل نه کاروي، مګر دا پخپله د کاروونکي ځای کې کوي، نو دا اختیار به د MetalLB عملیات اغیزه ونکړي.

راځئ چې بیرته خپل کار ته راشو. که د جاري شوي پتې لپاره لاره ستاسو په نوډونو کې شتون ونلري، نو مخکې له دې ټولو نوډونو ته اضافه کړئ:

ip route add 10.9.8.0/24 dev eth1

دریمه قضیه: کله چې تاسو د سرچینې پر بنسټ روټینګ ته اړتیا لرئ

تاسو به د سرچینې پر بنسټ روټینګ تنظیم کولو ته اړتیا ولرئ کله چې تاسو د جلا دروازې له لارې پاکټونه ترلاسه کوئ، نه چې د ډیفالټ لخوا ترتیب شوی وي، نو له همدې امله د غبرګون پاکټونه باید د ورته دروازې له لارې لاړ شي.

د مثال په توګه، تاسو ورته سبنټ لرئ 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 بلاک ډیاګرام دی:

لومړی، لکه څنګه چې په تیرو مثال کې، راځئ چې یو اضافي روټینګ جدول جوړ کړو:

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.

پدې توګه ، په بل انٹرفیس کې ترلاسه شوي نور پاکټونه د دې قاعدې تابع ندي ، کوم چې به دوی ته اجازه ورکړي چې د معیاري کبرنیټ وسیلو په کارولو سره وګرځي.

یو بل شی هم شتون لري ، په لینکس کې یو تش په نوم ریورس لارې فلټر شتون لري ، کوم چې ټول شیان خرابوي؛ دا یو ساده چک ترسره کوي: د ټولو راتلونکو پاکټونو لپاره ، دا د لیږونکي پتې سره د پاکټ سرچینه پته بدلوي او ګوري چې ایا کڅوړه کولی شي د ورته انٹرفیس له لارې پریږدي چې دا ترلاسه شوی و، که نه، دا به یې فلټر کړي.

ستونزه دا ده چې زموږ په قضیه کې دا به په سمه توګه کار ونکړي، مګر موږ کولی شو دا غیر فعال کړو:

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 تطبیق وکاروو. د iptables ماډل په توګه د rpfilter کارول، تاسو کولی شئ خورا انعطاف وړ قواعد تنظیم کړئ، د بیلګې په توګه:

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