जब दो अपलिंक एक ही 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 इसके पीछे का ज़ोन मॉडल बताता है, और इसीलिए नीति तालिका को हर लिंक-लोकल अगले हॉप के साथ एक डिवाइस रखनी पड़ती है।

कोई VPN कॉन्फ़िगरेशन जनरेटर जो एक होस्ट से संख्यात्मक ज़ोन ID कॉपी करके टेम्पलेट में डालता है, स्थानीय संदर्भ को पते का हिस्सा मान रहा है, और जो फ़ाइल वह लिखता है वह हर उस मशीन पर गलत होती है जिसके इंटरफ़ेस नाम या इंडेक्स अलग हैं। नीति तालिका दो लिंक को एक में नहीं मिलाती: रूटेड 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 से जोड़ा गया है वह रीबूट तक या कुछ उसे फ़्लश करने तक टिकता है। राउटर विज्ञापनों से सीखा डिफ़ॉल्ट लाइफ़टाइम रखता है और राउटर उसे वापस ले सकता है, जबकि हाथ से जोड़ा डिफ़ॉल्ट अपने आप कभी समाप्त नहीं होता। दोनों को एक तालिका में मिलाना ही वह तरीका है जिससे पुराना स्थायी रूट ताज़ा विज्ञापित रूट से ऊपर रह जाता है, उस अपलिंक के बहुत बाद जिसका वह वर्णन करता था, वह अस्तित्व में नहीं रहा।

हर तालिका के लिए एक मालिक चुनें। अगर नेटवर्क मैनेजर या रूटिंग डेमॉन पहले से इंटरफ़ेस संभालता है, वहीं नीति रूट लिखें और कर्नेल को छोड़ दें। अगर आप इसे स्क्रिप्ट कर रहे हैं, तो स्क्रिप्ट को idempotent बनाएँ और साथ ही टियरडाउन लिखें, क्योंकि पहले बुरे बदलाव के दौरान आपको उसकी ज़रूरत पड़ेगी:

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 फिर पढ़ें, और डिफ़ॉल्ट रूट लेने वाले पिंग के बजाय नियम से मेल खाते ट्रैफ़िक से परखें। फिर जानबूझकर एक अपलिंक नीचे करें और देखें कर्नेल किस रूट पर लौटता है; जवाब वही होना चाहिए जो आपने लिखा था।