राउटेड VPN पर IPv6 पड़ोसी खोज क्यों विफल होती है

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

दायरा कॉन्फ़िगरेशन से पहले आता है

पड़ोसी अनुरोध और घोषणा में 255 हॉप सीमा होती है और डिज़ाइन के अनुसार वे अग्रेषित नहीं होते। आपकी टनल और दूरस्थ LAN के बीच का राउटर IPv6 पैकेट अग्रेषित करता है और उसकी ओर से पड़ोसी संदेशों को रिले नहीं करता। इसलिए टनल इंटरफ़ेस पर पड़ोसी कैश में साथी और थोड़ा और ही रहता है, जो सही व्यवहार है, सुधारने योग्य दोष नहीं।

fe80:: जैसी प्रविष्टि वाला लिंक-स्थानीय पता भी ज़ोन-सीमित होता है, और वही पाठ किसी दूसरे लिंक पर किसी दूसरे होस्ट को दर्शा सकता है। टनल के दूसरी ओर से एक को परखना इसके सिवा कुछ सिद्ध नहीं करता कि पता अस्पष्ट है।

जाल यह मान लेना है कि उपसर्ग लिंक पर है

जो होस्ट मानता है कि उपसर्ग लिंक पर है, वह पैकेट अपने राउटर को सौंपने के बजाय पड़ोसी अनुरोध भेजता है, और इसमें दूरस्थ साइट पर राउट किया गया /64 भी शामिल है। जब ऐसा उपसर्ग लिंक पर होने के रूप में आता है, तो होस्ट स्थानीय लिंक से कहीं और रहने वाले होस्ट के बारे में पूछता है, और कोई उत्तर नहीं देता। दूरस्थ होस्ट के लिए कुछ छोटा राउट करें, या उपसर्ग को उस राउटर पर समाप्त करें जो उसकी ओर से उत्तर देगा।

एक ही सेवा के लिए /128 सबसे कम चौंकाने वाली व्यवस्था है, और यह अस्पष्टता को पूरी तरह हटा देती है। पड़ोसी खोज विनिर्देश संदेश-समुच्चय और इसे तय करने वाला लिंक-पर-है ध्वज का वर्णन करता है।

ब्रिजिंग जानबूझकर नियम बदलती है

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

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

उस पते से परखें जो एप्लिकेशन उपयोग करता है

ip -6 route get से मार्ग की पुष्टि करें, ip -6 neigh से पड़ोसी प्रविष्टि देखें, फिर राउटेड पथ पर सेवा की पुष्टि करें। DNS और वापसी पथ अलग जाँचें हैं, और स्वस्थ पड़ोसी प्रविष्टि इनमें से किसी को सिद्ध नहीं करती।

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

लिख लें कि आपके पास कौन-सा डिज़ाइन है

घटना से पहले दर्ज करें कि यह राउटेड है या ब्रिज्ड, क्योंकि दोनों परिनियोजन इन प्रश्नों का अलग उत्तर देते हैं और ऑन-कॉल इंजीनियर को इसे प्रोफ़ाइल से अनुमान नहीं लगाना चाहिए।

संदेश-समुच्चय को एक बार पढ़ लेने से लिंक-दायरे के गुण को VPN दोष बताने का प्रलोभन हट जाता है, जो इस क्षेत्र में सबसे महँगा गलत निदान है।