तुमच्या 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 ने दुरुस्त करता येत नाही।