کچھ عرصہ قبل مجھے 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 جوابات بھیجے گا، اس طرز عمل کو درست سمجھا جاتا ہے اور اس کے علاوہ، 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-запросов, а делает это самостоятельно в user-space, таким образом данная опция не повлияет на работу 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 اسے ہماری پہلی پوڈ پر بھیجے، جس نے اصل درخواست تیار کی تھی۔

اس مسئلے کو حل کرنا مشکل نکلا، لیکن پالیسی پر مبنی روٹنگ کی بدولت یہ ممکن ہوا:

اس عمل کی بہتر تفہیم کے لیے، یہاں ایک نیٹ فلٹر بلاک ڈایاگرام ہے:

پہلے، پچھلی مثال کی طرح، آئیے ایک اضافی روٹنگ ٹیبل بنائیں:

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 نفاذ کا استعمال کر سکتے ہیں۔ 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