दोन अपलिंक एकच 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 ऐवजी नियमाशी जुळणाऱ्या रहदारीने चाचणी करा। मग एक अपलिंक जाणीवपूर्वक खाली करा आणि कर्नेल कोणत्या मार्गावर माघार घेते ते पहा; उत्तर तुम्ही लिहिलेल्या मार्गाशी जुळले पाहिजे।