IPv6 छिमेकी पत्ता लगाउने काम रुट गरिएको VPN मा किन असफल हुन्छ

IPv6 छिमेकी पत्ता लगाउने काम एउटा लिङ्कको हो, र रुट गरिएको सुरुङ दुई लिङ्कबीचको सीमा हो। त्यो एक वाक्यले ठेगानाबाट जवाफ दिने तर अरू कुनै उपायले नभेटिने टाढाको होस्टबारे लगभग सबै प्रतिवेदनको व्याख्या गर्छ। सुरुङ जाँच्नुअघि तपाईंले परीक्षण गर्दै हुनुभएको ठेगानाको दायरा जाँच्नुहोस्। लिङ्कको स्थानीय ठेगाना आफ्नै लिङ्कमा मात्र अर्थपूर्ण हुन्छ, र अनुरोध गरिएको नोडको मल्टिकास्ट समूह पनि त्यसै गरी सीमित हुन्छ। यीमध्ये कुनै पनि राउटर पार गर्दैन, त्यसैले विश्वव्यापी ठेगानामा ping सफल हुन सक्छ जबकि त्यही होस्टको पत्ता लगाउने काम असफल हुन्छ।

दायरा कन्फिगरेसनभन्दा पहिले आउँछ

छिमेकी अनुरोध र घोषणाले 255 हप सीमा बोक्छन् र डिजाइनअनुसार अगाडि पठाइँदैनन्। तपाईंको सुरुङ र टाढाको LAN बीचको राउटरले IPv6 प्याकेट अगाडि पठाउँछ र यसको तर्फबाट छिमेकी सन्देशहरू रिले गर्दैन। त्यसैले सुरुङ इन्टरफेसमा रहेको छिमेकी क्यासमा साथी र थोरै मात्र हुन्छ, जुन सही व्यवहार हो, सुधार्नुपर्ने त्रुटि होइन।

fe80:: जस्तो प्रविष्टि भएको लिङ्कको स्थानीय ठेगाना पनि क्षेत्र-सीमित हुन्छ, र त्यही पाठले अर्को लिङ्कमा अर्को होस्ट जनाउन सक्छ। सुरुङको अर्को छेउबाट एउटा परीक्षण गर्दा ठेगाना अस्पष्ट छ भन्नेबाहेक केही प्रमाणित हुँदैन।

जाल भनेको प्रिफिक्स लिङ्कमा छ भन्ने अनुमान हो

प्रिफिक्स लिङ्कमा छ भनी ठान्ने होस्टले प्याकेट आफ्नो राउटरलाई दिनुको सट्टा छिमेकी अनुरोध पठाउँछ, र यसमा टाढाको साइटमा रुट गरिएको /64 पनि पर्छ। त्यस्तो प्रिफिक्स लिङ्कमा रहेको रूपमा आउँदा, होस्टले स्थानीय लिङ्कलाई अन्त कतै बस्ने होस्टबारे सोध्छ, र कसैले जवाफ दिँदैन। टाढाको होस्टतर्फ केही सानो रुट गर्नुहोस्, वा प्रिफिक्सलाई यसको तर्फबाट जवाफ दिने राउटरमा अन्त्य गर्नुहोस्।

एउटै सेवाका लागि /128 सबैभन्दा कम अचम्मको व्यवस्था हो, र यसले अस्पष्टता पूर्ण रूपमा हटाउँछ। छिमेकी पत्ता लगाउने विशिष्टता ले सन्देश-समूह र यो निर्धारण गर्ने लिङ्कमा-छ झन्डाको वर्णन गर्छ।

ब्रिजिङले जानाजान नियम बदल्छ

जब सुरुङले Ethernet फ्रेम बोक्छ, टाढाको र स्थानीय खण्ड एउटै लिङ्क बन्छन्, मल्टिकास्ट दुवैतिर पुग्छ, र छिमेकी पत्ता लगाउने काम स्विचमा जस्तै व्यवहार गर्छ। परिणामहरू पनि सँगै आउँछन्: ब्रोडकास्ट र मल्टिकास्ट बाढी, पुलभरि दोहोरिएका ठेगाना पहिचान, र नदेख्नुपर्ने खण्डमा चुहिने राउटर घोषणाहरू। असफलताको क्षेत्र अब दुई साइटसम्म फैलिन्छ। यीमध्ये केही पनि पुलविरुद्धको तर्क होइन, र प्रत्येक बुँदा पुल संयोगले होइन, जानाजान बनाउनुको कारण हो।

पत्ता लगाउने काम देखियोस् भनेर प्रोफाइल TUN बाट TAP मा बदल्नु कार्यको गलत क्रम हो। सर्भर, क्लाइन्ट र ठेगाना योजना—सबै सहमत हुनुपर्छ, र मोबाइल क्लाइन्टले TAP इन्टरफेस दिँदै दिँदैनन्, त्यसैले त्यस्तो डिजाइन ल्यापटपमा चल्छ र फोनमा असफल हुन्छ। छिमेकी प्रोक्सी र रिले आफ्नै आवश्यकतासहितका छुट्टै संयन्त्र हुन्, र ती एपका सेटिङको होइन, नेटवर्क प्रशासकको अभिलिखित व्यवस्थाको हुन्।

एप्लिकेसनले प्रयोग गर्ने ठेगानाबाटै परीक्षण गर्नुहोस्

ip -6 route get ले मार्ग पुष्टि गर्नुहोस्, ip -6 neigh ले छिमेकी प्रविष्टि हेर्नुहोस्, त्यसपछि रुट गरिएको मार्गमा सेवा पुष्टि गर्नुहोस्। DNS र फर्कने मार्ग छुट्टै जाँच हुन्, र स्वस्थ छिमेकी प्रविष्टिले यीमध्ये कुनै पनि प्रमाणित गर्दैन।

यदि एप्लिकेसनले लिङ्कको स्थानीय वा पत्ता-लगाउने आधारित गन्तव्यमा जोड दिन्छ भने त्यो ट्युनिङ अभ्यास होइन, डिजाइन वार्तालाप हो, किनभने कुनै क्लाइन्ट सेटिङले लिङ्क-सीमित संयन्त्रलाई राउटरभरि काम गर्ने बनाउँदैन।

तपाईंसँग कुन डिजाइन छ लेख्नुहोस्

घटनाभन्दा पहिले यो रुट गरिएको हो वा पुल गरिएको हो अभिलेख गर्नुहोस्, किनभने दुई परिनियोजनले यी प्रश्नको फरक जवाफ दिन्छन् र ड्युटीमा रहेको इन्जिनियरले यो प्रोफाइलबाट अनुमान गर्नु हुँदैन।

सन्देश-समूह एक पटक पढ्दा लिङ्क-दायराको गुणलाई VPN त्रुटि भनी व्याख्या गर्ने प्रलोभन हट्छ, जो यस क्षेत्रको सबैभन्दा महँगो गलत निदान हो।