ICMP रीडायरेक्ट बनाम आपके VPN रूट: वास्तव में क्या बदलता है

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

रीडायरेक्ट राउटर की ओर से एक सुझाव है

IPv4 में ICMP रीडायरेक्ट का अपना संदेश-प्रकार और सीमित शर्तें हैं: राउटर पैकेट को उसी इंटरफ़ेस से आगे भेजता है जिससे वह आया था, और वह उसी लिंक पर गंतव्य के निकट एक अगला हॉप जानता है। फिर वह प्रेषक से कहता है कि सीधे उसी अगले हॉप का उपयोग करे। संदेश नए गेटवे का नाम लेता है और मूल पैकेट का एक भाग शामिल करता है ताकि प्रेषक उसे किसी फ़्लो से मिला सके। यह स्थानीय टोपोलॉजी के बारे में एक शिष्टाचार संदेश है, और यह मानता है कि प्रेषक सुझाए गए गेटवे के साथ लिंक साझा करता है।

प्रेषक इसे अनदेखा करने के लिए स्वतंत्र है। प्रोटोकॉल में कुछ भी होस्ट से अपनी तालिका बदलने की मांग नहीं करता, और पकड़ा गया रीडायरेक्ट केवल यह सिद्ध करता है कि किसी राउटर ने एक भेजा था।

इसी भेद में अधिकांश रीडायरेक्ट जांचें गलत दिशा में जाती हैं।

IPv4 और IPv6 इसे अलग तरह से पहुँचाते हैं

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

नीति के नॉब भी अलग हैं, इसलिए होस्ट IPv4 रीडायरेक्ट स्वीकार कर सकता है और IPv6 को अनदेखा कर सकता है, या उल्टा।

यदि विचाराधीन फ़्लो दोनों में से कोई भी उपयोग कर सकती है तो दोनों परिवार जांचें।

स्वीकृति होस्ट की नीति है, नेटवर्क का तथ्य नहीं

Linux में रीडायरेक्ट की स्वीकृति प्रति इंटरफ़ेस और वैश्विक रूप से नियंत्रित होती है, और डिफ़ॉल्ट होस्ट तथा राउटर भूमिकाओं में अलग होते हैं। रीडायरेक्ट स्वीकार करने वाला टनल इंटरफ़ेस विचित्र डिज़ाइन है, क्योंकि बिंदु-से-बिंदु टनल के भीतर उसी लिंक पर कोई सार्थक वैकल्पिक अगला हॉप नहीं होता। इसलिए उस सेटिंग को मानने के बजाय पढ़ना चाहिए।

सुरक्षित-रीडायरेक्ट सेटिंग्स और सीमित करती हैं कि किन गेटवे पर विश्वास किया जा सके।

यदि आप किसी होस्ट को कठोर बना रहे हैं, तो यही समीक्षा करने योग्य नॉब हैं, और यही कारण है कि एक ही नेटवर्क पर दो मशीनें अलग व्यवहार कर सकती हैं। इन्हें नीति के रूप में बदलें, डिबगिंग के शॉर्टकट के रूप में नहीं।

रीडायरेक्ट क्या नहीं समझा सकता

विशिष्ट रूट, नीति-रूटिंग नियम और स्थानीय इंटरफ़ेस बिना किसी रीडायरेक्ट के अधिकांश अप्रत्याशित पथ समझा देते हैं। अधिक विशिष्ट प्रीफ़िक्स, स्रोत पते से मेल खाता नियम, या किसी दूसरी तालिका में दूसरा डिफ़ॉल्ट इनमें से प्रत्येक उस रूट को पछाड़ देगा जिसकी आपको अपेक्षा थी। पहले इन्हीं को जांचें, क्योंकि ये नियतात्मक और दृश्य हैं।

पुराने कैप्चर दूसरा जाल हैं, क्योंकि नेटवर्क बदलने वाले क्लाइंट का स्थानीय गेटवे अलग होता है।

पिछले जुड़ाव का पुराना रीडायरेक्ट वर्तमान पथ के बारे में कुछ नहीं बताता, इसलिए दर्ज करें कि अब कौन-सा इंटरफ़ेस नियंत्रण-ट्रैफ़िक प्राप्त करता है।

टनल को दोष देने से पहले रूट जांचें

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

रीडायरेक्ट कभी इसका कारण नहीं होना चाहिए कि कोई संरक्षित पथ चुपचाप असंरक्षित हो जाए, और इसीलिए स्वीकृति नीति डिज़ाइन समीक्षा में आती है। RFC 792 की परिभाषा इस बात का संदर्भ बनी रहती है कि IPv4 संदेश क्या कह सकता है।

रूट लुकअप और कैप्चर का समय-चिह्न साथ लिखें, फिर अगला व्यक्ति आपके निष्कर्ष को दोहरा सकेगा।