केही समय अघि मैले MetalLB को लागि रूटिङ सेटअप गर्ने धेरै असामान्य कार्यको सामना गर्नुपरेको थियो। सबै ठीक हुनेछ, किनभने ... सामान्यतया MetalLB लाई कुनै पनि अतिरिक्त कार्यहरू आवश्यक पर्दैन, तर हाम्रो केसमा हामीसँग धेरै साधारण नेटवर्क कन्फिगरेसनको साथ एकदम ठूलो क्लस्टर छ।

यस लेखमा म तपाइँलाई तपाइँको क्लस्टरको बाह्य नेटवर्कको लागि स्रोत-आधारित र नीति-आधारित राउटिङ कसरी कन्फिगर गर्ने भनेर बताउनेछु।

म MetalLB स्थापना र कन्फिगर गर्ने बारे विस्तारमा जानेछैन, किनकि म मान्छु कि तपाईसँग पहिले नै केहि अनुभव छ। म सिधा बिन्दुमा जाने सुझाव दिन्छु, अर्थात् मार्ग सेट अप गर्नुहोस्। त्यसोभए हामीसँग चारवटा केसहरू छन्:

केस १: जब कुनै कन्फिगरेसन आवश्यक पर्दैन

एक साधारण मामला हेरौं।

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) ठेगाना कुनै पनि नोड इन्टरफेसमा जोडिएको छ (उदाहरणका लागि लुपब्याक)। यहाँ लिनक्स नेटवर्क स्ट्याकका सुविधाहरू उल्लेख गर्न लायक छ। तपाईंले कुन इन्टरफेसमा ठेगाना थप्नुभए पनि, कर्नेलले जहिले पनि एआरपी अनुरोधहरू प्रशोधन गर्नेछ र ती मध्ये कुनैमा पनि एआरपी प्रतिक्रियाहरू पठाउनेछ, यो व्यवहारलाई सही मानिन्छ र यसबाहेक, कुबर्नेट्स जस्ता गतिशील वातावरणमा व्यापक रूपमा प्रयोग गरिन्छ।

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

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

यस अवस्थामा, एआरपी प्रतिक्रियाहरू मात्र पठाइनेछ यदि इन्टरफेसमा स्पष्ट रूपमा एक विशिष्ट 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

केस ४: जब तपाईलाई नीतिमा आधारित रुटिङ चाहिन्छ

नेटवर्क टोपोलोजी अघिल्लो उदाहरणमा जस्तै छ, तर मानौं कि तपाईं बाह्य पूल ठेगानाहरू पहुँच गर्न सक्षम हुन चाहनुहुन्छ। 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 सक्षम गरि रहनेछन्।

फिल्टरको सञ्चालनलाई पूर्ण रूपमा सीमित नगर्नको लागि, हामी 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