कुछ समय पहले मुझे मेटलएलबी के लिए रूटिंग स्थापित करने के एक बहुत ही असामान्य कार्य का सामना करना पड़ा था। सब कुछ ठीक होगा, क्योंकि... आमतौर पर मेटलएलबी को किसी अतिरिक्त कार्रवाई की आवश्यकता नहीं होती है, लेकिन हमारे मामले में हमारे पास बहुत ही सरल नेटवर्क कॉन्फ़िगरेशन के साथ काफी बड़ा क्लस्टर है।

इस लेख में मैं आपको बताऊंगा कि अपने क्लस्टर के बाहरी नेटवर्क के लिए स्रोत-आधारित और नीति-आधारित रूटिंग को कैसे कॉन्फ़िगर करें।

मैं मेटलएलबी को स्थापित करने और कॉन्फ़िगर करने के बारे में विस्तार से नहीं बताऊंगा, क्योंकि मेरा मानना ​​है कि आपके पास पहले से ही कुछ अनुभव है। मेरा सुझाव है कि सीधे मुद्दे पर जाएं, अर्थात् रूटिंग सेट करें। तो हमारे पास चार मामले हैं:

केस 1: जब किसी कॉन्फ़िगरेशन की आवश्यकता नहीं है

आइए एक साधारण मामले पर नजर डालें।

जब मेटलएलबी द्वारा जारी पते आपके नोड्स के पते के समान सबनेट में हों तो अतिरिक्त रूटिंग कॉन्फ़िगरेशन की आवश्यकता नहीं होती है।

उदाहरण के लिए, आपके पास एक सबनेट है 192.168.1.0/24, इसमें एक राउटर है 192.168.1.1, और आपके नोड्स को पते प्राप्त होते हैं: 192.168.1.10-30, फिर मेटलएलबी के लिए आप रेंज को समायोजित कर सकते हैं 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: जब अतिरिक्त अनुकूलन की आवश्यकता होती है

जब भी आपके नोड्स में कॉन्फ़िगर आईपी पता या सबनेट के लिए रूट नहीं होता है, जिसके लिए मेटलएलबी पते जारी करता है, तो आपको अतिरिक्त रूट कॉन्फ़िगर करना चाहिए।

मैं थोड़ा और विस्तार से बताऊंगा. जब भी MetalLB कोई पता आउटपुट करता है, तो इसकी तुलना एक साधारण असाइनमेंट से की जा सकती है जैसे:

ip addr add 10.9.8.7/32 dev lo

पर ध्यान दें:

• a) पता एक उपसर्ग के साथ निर्दिष्ट किया गया है /32 अर्थात्, इसके लिए कोई रूट स्वचालित रूप से सबनेट में नहीं जोड़ा जाएगा (यह सिर्फ एक पता है)
• b) पता किसी भी नोड इंटरफ़ेस से जुड़ा हुआ है (उदाहरण के लिए लूपबैक)। यहां लिनक्स नेटवर्क स्टैक की विशेषताओं का उल्लेख करना उचित है। इससे कोई फर्क नहीं पड़ता कि आप किस इंटरफ़ेस में पता जोड़ते हैं, कर्नेल हमेशा arp अनुरोधों को संसाधित करेगा और उनमें से किसी को arp प्रतिक्रिया भेजेगा, इस व्यवहार को सही माना जाता है और, इसके अलावा, Kubernetes जैसे गतिशील वातावरण में काफी व्यापक रूप से उपयोग किया जाता है।

इस व्यवहार को अनुकूलित किया जा सकता है, उदाहरण के लिए सख्त एआरपी को सक्षम करके:

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

इस मामले में, एआरपी प्रतिक्रियाएं केवल तभी भेजी जाएंगी जब इंटरफ़ेस में स्पष्ट रूप से एक विशिष्ट आईपी पता शामिल होगा। यदि आप मेटलएलबी का उपयोग करने की योजना बना रहे हैं और आपका क्यूब-प्रॉक्सी आईपीवीएस मोड में चल रहा है तो यह सेटिंग आवश्यक है।

हालाँकि, 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 वीएलएएन 100 में स्थित है और आप बाहरी रूप से कुबेरनेट्स सेवाओं तक पहुंचने के लिए उनका उपयोग करना चाहते हैं।

संपर्क करते समय 1.2.3.4 आप किसी भिन्न सबनेट से अनुरोध कर रहे होंगे 1.2.3.0/24 और उत्तर की प्रतीक्षा करें. वह नोड जो वर्तमान में मेटलएलबी द्वारा जारी पते का मास्टर है 1.2.3.4, राउटर से पैकेट प्राप्त करेगा 1.2.3.1, लेकिन उसके लिए उत्तर आवश्यक रूप से उसी मार्ग से जाना चाहिए 1.2.3.1.

चूँकि हमारे नोड में पहले से ही एक डिफ़ॉल्ट गेटवे कॉन्फ़िगर है 192.168.1.1, तो डिफ़ॉल्ट रूप से प्रतिक्रिया उसके पास जाएगी, न कि उसके पास 1.2.3.1जिसके माध्यम से हमें पैकेज प्राप्त हुआ।

इस स्थिति से कैसे निपटें?

इस मामले में, आपको अपने सभी नोड्स को इस तरह से तैयार करने की आवश्यकता है कि वे अतिरिक्त कॉन्फ़िगरेशन के बिना बाहरी पते की सेवा के लिए तैयार हों। अर्थात्, उपरोक्त उदाहरण के लिए, आपको पहले से नोड पर एक वीएलएएन इंटरफ़ेस बनाना होगा:

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, लेकिन हम चाहते हैं कि कुबेरनेट्स इसे हमारे पहले पॉड पर रीडायरेक्ट करे, जिसने मूल अनुरोध उत्पन्न किया।

इस समस्या को हल करना कठिन हो गया, लेकिन नीति-आधारित रूटिंग के कारण यह संभव हो गया:

प्रक्रिया की बेहतर समझ के लिए, यहां एक नेटफ़िल्टर ब्लॉक आरेख है:

सबसे पहले, पिछले उदाहरण की तरह, आइए एक अतिरिक्त रूटिंग टेबल बनाएं:

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 सक्षम के साथ बने रहेंगे।

फ़िल्टर के संचालन को पूरी तरह से सीमित न करने के लिए, हम नेटफ़िल्टर के लिए 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