दुई अपलिङ्कले fe80::1 साझा गर्दा IPv6 नीति रुटिङ

तपाईंसँग दुई अपलिङ्क छन्, र ip -6 route show दुवैमा एउटै अर्को होप छाप्छ: default via fe80::1 dev uplink0 र default via fe80::1 dev uplink1। यो ठेगाना दोहोरिने द्वन्द्व होइन, र खाली अर्को होप fe80::1 नीति तालिकामा प्रतिलिपि गर्दा कर्नेललाई तपाईंले कुन लिङ्क भन्नुभयो भन्ने थाहा हुँदैन। साँचो प्रश्न लक्षणले सुझाएभन्दा साँघुरो छ: दोस्रो तालिकालाई एउटा लिङ्क चाहिन्छ कि दुवै, र रिबुटपछि ती रुटहरूलाई केले जिउँदो राख्छ। क्रमैसँग जाँचिएका तीन सर्तले धेरैजसो टुंग्याउँछन्।

उही fe80::1 दुई फरक छिमेकी हुन्

लिङ्क-स्थानीय ठेगानाहरू एउटै लिङ्कमा सीमित हुन्छन्, त्यसैले fe80::1 दुई पटक छापिएको एउटै ठेगाना होइन; ती एउटै प्रत्यय साझा गर्ने दुई छिमेकी हुन्। जोन इन्डेक्स भनेको होस्टले कुन चाहिं भनेको हो भन्ने बताउने तरिका हो, त्यसैले fe80::1%uplink0 र fe80::1%uplink1 कर्नेलका लागि फरक गन्तव्य हुन्, र त्यो प्रत्यय कहिल्यै टाढाको राउटरमा जाँदैन। RFC 4007 यसपछाडिको जोन मोडेल वर्णन गर्छ, र त्यसैले नीति तालिकाले प्रत्येक लिङ्क-स्थानीय अर्को होपसँगै यन्त्र बोक्नुपर्छ।

एउटा होस्टको अंकीय जोन ID टेम्प्लेटमा प्रतिलिपि गर्ने VPN कन्फिगरेसन जेनेरेटरले स्थानीय सन्दर्भलाई ठेगानाको भाग जस्तै व्यवहार गर्छ, र त्यसले लेख्ने फाइल इन्टरफेस नाम वा इन्डेक्स फरक हुने हरेक मेसिनमा गलत हुन्छ। नीति तालिकाले दुई लिङ्कलाई एउटा बनाएर मिलाउँदैन: रुट गरिएको VPN ले सञ्जालहरूबीच प्याकेट पास गर्छ, तर टाढाको इथरनेट छिमेकीको लिङ्क-स्थानीय परिचय सुरुङभरि बोक्दैन, त्यसैले लिङ्क-स्थानीय ट्राफिक आफ्नै लिङ्कमा रहन्छ।

यन्त्र हटाउनुहोस्, रुट लेख्न नसकिने हुन्छ। ip -6 route add default via fe80::1 table 200 ले गेटवे समाधान गर्न सक्दैन, र iproute2 ले यसलाई Error: Nexthop has invalid gateway. त्रुटिले अस्वीकार गर्छ। dev uplink0 थप्नुहोस्, आदेश सफल हुन्छ, किनकि अर्को होपलाई ती दुई छिमेकीमध्ये एउटामा टाँस्ने यन्त्र नै हो। यन्त्रले भन्न नसक्ने कुरा हो—uplink0 यो तालिकाका लागि सही लिङ्क हो कि होइन, र अर्को होस्टबाट प्रतिलिपि गरिएको रुटले त्यो होस्टका इन्टरफेस नामहरू सँगै ल्याउँछ, साँचो गल्तीहरू यहीँबाट आउँछन्।

सर्त एक: तालिकामा एउटा लिङ्क कि दुई

दोस्रो अपलिङ्क केका लागि हो त्यसबाट सुरु गर्नुहोस्। दुवै लिङ्कले एउटै ट्राफिक बोक्छन् र एउटा जगेडा हो भने, वैकल्पिक तालिकामा दुवै गेटवे फरक मेट्रिकसहित राख्नुपर्छ: उही गन्तव्य, एउटा प्राथमिक मार्ग, एउटा स्पष्ट दोस्रो विकल्प। फरक ट्राफिक फरक प्रदायकबाट बाहिर जानुपर्ने भएर, वा यो विभाजित सुरुङ भएर जसमा केही ट्राफिक VPN छल्छ र बाँकी भित्र रहन्छ, अपलिङ्कहरू छन् भने, ती दुई लिङ्क एउटै तालिकामा पटक्कै पर्दैनन्। ती दुई तालिकामा पर्छन्, तिनलाई एउटा नियमले छान्छ, र नियमले सुरुङ होइन, तालिका छान्छ: छल्ने ट्राफिक रुटिङ अघि चिन्ह लगाइन्छ, र त्यो चिन्हले नै त्यसलाई दोस्रो तालिकामा पठाउँछ।

त्यो दोस्रो अवस्थामा नियमले तालिका कहिले हेर्ने भन्ने निर्धारण गर्छ, र रुटले प्याकेट कहाँ जाने भन्ने निर्धारण गर्छ:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

कुनै पनि वस्तुले अर्कोलाई प्रतिस्थापन गर्दैन, र केवल पूर्वनिर्धारित राख्ने तालिकाले पनि आफ्नो गेटवे समाधान गर्न नसक्ने हुन सक्छ। थप अस्वीकार भयो, वा रुट छ तर प्रयोगयोग्य छैन भने, त्यो इन्टरफेसको जोडिएको प्रिफिक्स त्यही तालिकामा राख्नुहोस्, वा होपलाई onlink भनेर चिन्ह लगाउनुहोस् (त्यो प्रिफिक्स अन्तै रुट हुँदा)। माथिको ब्लकमा 2001:db8:100::/48 ले कुनै स्वेच्छाचारी गन्तव्य होइन, uplink1 मा त्यो जोडिएको प्रिफिक्स जनाउँछ। fwmark नियमले अरू कुनैले सेट गर्नुपर्ने चिन्ह मात्र खपत गर्छ: फर्वार्डिङ मार्गको nftables वा iptables नियमबाट, वा SO_MARK सकेटमा, त्यसैले चिन्हको स्रोत बिना प्रतिलिपि गरिएको ब्लक केहीसँग मिल्दैन।

सर्त दुई: मेट्रिकले मृत प्रदायक पत्ता लगाउँदैन

मेट्रिक भनेको अवस्थित रुटहरूबीचको प्राथमिकता हो, स्वास्थ्य जाँच होइन। वाहक खस्दा कर्नेलले त्यो यन्त्रका रुटहरू हटाउँछ र दोस्रो पूर्वनिर्धारितले लिन्छ। केबल चालु रहँदा त्यसपछाडिको प्रदायक मर्छ भने तालिकामा केही बदलिँदैन: प्राथमिक रुट जडान भएको हुन्छ, छिमेकी तह 2 मा पुग्नयोग्य हुन्छ, र प्याकेटहरू कालो प्वालमा निस्कन्छन्। यो भिन्नता तपाईंको सेटअपका लागि महत्त्वपूर्ण भए, असफलता सर्ने काम मार्ग जाँच्ने र रुट हटाउने कुनै कुराबाट आउनुपर्छ: त्यो रुटिङ डेमन होस्, वा प्रविष्टि मेटेर फेरि जडान गर्ने सानो स्क्रिप्ट होस्।

तालिका बनिसकेपछि छनोट प्रमाणित गर्नुहोस्, र कर्नेलले देख्ने तरिकाले नै प्रमाणित गर्नुहोस्। ip -6 route get 2001:db8:100::1 ले प्रयोग हुने रुट छाप्छ, त्यसमा यन्त्र र छानिएको स्रोत ठेगाना समावेश हुन्छ, र यसले नीति नियमहरूको सम्मान गर्छ। गलत अपलिङ्कको स्रोत ठेगाना सामान्यतया नियम तपाईंले अपेक्षा गरेभन्दा चाँडै मिलेको संकेत हो।

सर्त तीन: दिगोपनको स्वामित्व कसको हो निर्धारण गर्नुहोस्

रुट ip -6 route add ले थपिएको रुट रिबुटसम्म वा कुनैले त्यसलाई फ्लस नगरेसम्म टिक्छ। राउटर विज्ञापनबाट सिकिएको पूर्वनिर्धारितले आयु बोक्छ र राउटरले फिर्ता लिन सक्छ, जबकि हातले थपिएको पूर्वनिर्धारित कहिल्यै आफैं सकिँदैन। दुईलाई एउटै तालिकामा मिसाउनु भनेको पुरानो स्थायी रुटले भर्खरै विज्ञापित रुटलाई पछाडि पार्ने तरिका हो, त्यसले वर्णन गरेको अपलिङ्क धेरै अघि नै नरहे पनि।

प्रत्येक तालिकाका लागि एउटा मालिक छान्नुहोस्। नेटवर्क म्यानेजर वा रुटिङ डेमनले पहिले नै इन्टरफेस सम्हाल्छ भने, नीति रुट त्यहीँ वर्णन गर्नुहोस् र कर्नेललाई छोड्नुहोस्। तपाईं स्क्रिप्टले गर्दै हुनुहुन्छ भने, स्क्रिप्टलाई इडेम्पोटेन्ट बनाउनुहोस् र भत्काउने काम पनि त्यही बेला लेख्नुहोस्, किनकि पहिलो नराम्रो परिवर्तनमै त्यो चाहिन्छ:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

अरू होस्टका लागि फर्वार्ड गर्ने राउटरमा, तालिकालाई दोष दिनुअघि net.ipv6.conf.all.forwarding जाँच्नुहोस्। फर्वार्डिङ बन्द भए, अर्को सञ्जालमा ठेगाना गरिएका प्याकेटहरू तालिका 201 जतिसुकै सही भए पनि फालिन्छन्।

अर्को मानिसले अडिट गर्न सकून् भनेर डिजाइन लेख्नुहोस्

केवल fe80::1 भण्डारण गर्ने सूचीले महत्त्वपूर्ण फाँटहरू फाल्छ। गन्तव्य, अर्को होप, यन्त्र, तालिका र मेट्रिक सँगै लेख्नुहोस्, र प्रत्येक रुट कहाँबाट आयो पनि: विज्ञापित, म्यानेजरले बनाएको, वा स्थिर। पछि कसैले दोस्रो अपलिङ्कले साँच्चै ट्राफिक बोक्छ कि भनेर सोध्दा, त्यो अभिलेखले अनुमान बिना जवाफ दिन्छ।

तालिका सकियो भन्नुअघि, छिमेकीलाई ip -6 neigh show dev uplink0 ले प्रमाणित गर्नुहोस्, ip -6 rule show फेरि पढ्नुहोस् — क्रमका दुर्घटनाका लागि, र पूर्वनिर्धारित मार्ग लिने ping नभई नियमसँग मिल्ने ट्राफिकले परीक्षण गर्नुहोस्। त्यसपछि एउटा अपलिङ्क जानाजान बन्द गर्नुहोस् र कर्नेल कुन रुटमा फर्कन्छ हेर्नुहोस्; जवाफ तपाईंले लेखेकोसँग मिल्नुपर्छ।