तपाईंको 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 ले सुधार्न सकिँदैन।