आपके IPv6 टनल पीयर का ping विफल? :: पता जाँचें

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

वह लक्षण जो पते की ओर इशारा करता है

लिंक पर हर होस्ट उत्तर देता है सिवाय उसके जिसका इंटरफ़ेस पहचानकर्ता सब शून्य है। उस रूप को संबोधित पैकेट परिभाषा से सबनेट के राउटर को दिया जाता है, इसलिए पॉइंट-टू-पॉइंट टनल पर वह उसी मशीन के पास लौटता है जिसने उसे भेजा था। दूर के सिरे से यह अगम्य पीयर के रूप में पढ़ा जाता है; निकट के सिरे से यह मौन के रूप में पढ़ा जाता है। उसी प्रीफ़िक्स का कोई दूसरा पहचानकर्ता रखिए और बिना किसी अन्य बदलाव के लक्षण गायब हो जाता है, और रूट छूने से पहले यही पुष्टि लेनी चाहिए।

सभी-शून्य पहचानकर्ता anycast के रूप में आरक्षित है

RFC 4291 सभी-शून्य इंटरफ़ेस पहचानकर्ता को सबनेट-राउटर anycast पता रखता है, इसलिए /64 जैसा 2001:db8:4a::/64 में कोई उपयोगी होस्ट नहीं है 2001:db8:4a:: पर। यह आरक्षण अपनी जगह का हकदार है: राउटर घोषणाएँ और पड़ोसी खोज उसी रूप को संबोधित करती हैं, और राउटर उस प्रीफ़िक्स के लिए उत्तर देता है जिसकी वह सेवा करता है। उस मान को टनल सिरे पर निर्दिष्ट करने से एक पत्ती को राउटर की भूमिका मिल जाती है, और इसीलिए कुछ भी वापस नहीं आता। प्रीफ़िक्स में कोई भी अन्य पहचानकर्ता होस्ट की तरह काम करता है, इसलिए सुधार आमतौर पर एक अंक का होता है।

इस आरक्षण को ऐसी भूमिका मानिए जिसे टनल सिरे से लेने का आपको हक नहीं, न कि ऐसी विचित्रता जिसे रूट से बचा जाए।

होस्ट पते निर्दिष्ट करें और प्रीफ़िक्स को रूट करें

दोनों सिरों के लिए ::1 और ::2 चुनें, एक को इससे जोड़ें: ip -6 addr add 2001:db8:4a::2/64 dev tun0, और फिर दूर के प्रीफ़िक्स को पता देने की कोशिश करने के बजाय उसे रूट करें। 2001:db8:4a::/64 के लिए टनल से बाहर जाने वाला रूट दूर के हिस्से को पहुँच-योग्य बनाता है; अकेला पता केवल स्थानीय इंटरफ़ेस को कॉन्फ़िगर करता है।

पूर्ण टनल के लिए तीसरा चरण है, डिवाइस के माध्यम से वैश्विक unicast के लिए डिफ़ॉल्ट रूट, जो सब कुछ टनल में भेजने के IPv6 समतुल्य है। इसे छोड़ दें तो IPv4 टनल के भीतर यात्रा करते समय IPv6 भौतिक लिंक का उपयोग करता रहता है, इसलिए होस्ट ठीक वही ट्रैफ़िक लीक करता है जिसे आपने ढका हुआ माना था। इससे पुष्टि करें ip -6 route get 2001:4860:4860::8888 और उत्तर मान लेने के बजाय पढ़ें कि यह किस डिवाइस का नाम लेता है।

रूटिंग से पहले multicast अस्वीकार किया जाता है

Android VpnService.Builder के लिए पते और रूट LinkAddress के माध्यम से सत्यापित करता है, और वह कंस्ट्रक्टर multicast को सीधे अस्वीकार कर देता है। इसे रूट के रूप में multicast प्रीफ़िक्स दें तो परिणाम रूट नहीं, बल्कि खराब LinkAddress पैरामीटर की विफलता होती है, जो सत्यापन का उत्तर है, नेटवर्क का नहीं। यह अस्वीकृति माध्यम से मेल खाती है: पॉइंट-टू-पॉइंट tun डिवाइस में लिंक-स्तरीय multicast नहीं होता, इसलिए उस पर समूह रूट के पास स्थापित करने के लिए कोई डिलीवरी मॉडल नहीं है। समूह पते स्टैक स्वयं बनाता और उपभोग करता है, हाथ से कॉन्फ़िगर नहीं किए जाते।

IPv6 all-nodes और solicited-node पते उसी नियम के अंतर्गत आते हैं। इंटरफ़ेस उन्हें इसलिए वहन करता है क्योंकि स्टैक ने उन्हें वहाँ रखा है, इसलिए नहीं कि किसी नीति ने उनका इरादा किया था।

टनल इसके बजाय क्या वहन कर सकता है

टनल के आर-पार multicast खोज को स्थानांतरित करने के लिए एक ऐसी परत चाहिए जो समूह सदस्यता समझती हो: Ethernet खंड प्रस्तुत करने वाला TAP ब्रिज, अनुप्रयोग-स्तरीय रिले, या ऐसा रूटिंग प्रोटोकॉल जिसे स्पष्ट रूप से बताया गया हो कि किन पीयरों को प्रतिलिपि बनानी है। VpnService मॉडल में इनमें से कुछ भी नहीं है, जहाँ अनुप्रयोग पैकेट पढ़ता और लिखता है और टनल के लिए समूह में शामिल होने वाला कोई कॉल नहीं है। या तो समूह समझने वाला घटक जोड़ें या डिज़ाइन से यह आवश्यकता हटा दें।

इसके विपरीत unicast को ऊपर के पतों और रूटों के अलावा कुछ अतिरिक्त नहीं चाहिए, इसीलिए टनल से आमतौर पर यह अपेक्षा की जाती है कि वे इसे वहन करें, और फिर जब खोज प्रोटोकॉल विफल होता है तो उन्हें दोष दिया जाता है।

कुछ भी निर्दिष्ट करने से पहले तीन जाँचें

पुष्टि करें कि पता anycast रूप नहीं है, पुष्टि करें कि वह multicast नहीं है, और पुष्टि करें कि प्रीफ़िक्स रूट किया गया है, केवल डिवाइस को निर्दिष्ट नहीं। फिर अपना परीक्षण ऐसे गंतव्य पर भेजें जो वास्तविक होस्ट हो, क्योंकि anycast पते पर लक्षित ping प्रेषक को मापता है और मार्ग के बारे में कुछ नहीं बताता। उन तीन जाँचों को परिवर्तन-रिकॉर्ड में रखें ताकि अगली तैनाती उन्हें फिर से खोजे नहीं।

जिस रूट को प्लेटफ़ॉर्म ने कभी स्थापित नहीं किया उसे अधिक देर तक प्रतीक्षा करके डीबग नहीं किया जा सकता, और जो पता कभी होस्ट नहीं था उसे बेहतर ping से ठीक नहीं किया जा सकता।