ICMP रिडाइरेक्ट र तपाईंका VPN रुटहरू: वास्तवमा के फेरिन्छ

सुरुङबाट जानुपर्ने प्रवाहले अर्को अर्को हप छान्छ, र कसैले क्याप्चरमा एउटा ICMP रिडाइरेक्ट भेट्छ। त्यो एक परिकल्पना हो, निदान होइन। रिडाइरेक्ट भनेको राम्रो अर्को हपबारे राउटरको सुझाव हो, र होस्टले त्यसअनुसार काम गर्छ कि गर्दैन भन्ने प्लेटफर्म, इन्टरफेस र ठेगाना परिवारअनुसार फरक पर्ने सेटिङमा निर्भर गर्छ।

रिडाइरेक्ट राउटरबाट आएको सुझाव हो

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

पठाउनेलाई त्यसलाई बेवास्ता गर्ने स्वतन्त्रता छ। प्रोटोकलले होस्टलाई तालिका बदल्न बाध्य पार्दैन, र क्याप्चर गरिएको रिडाइरेक्टले राउटरले एउटा पठायो भन्ने मात्र प्रमाणित गर्छ।

धेरैजसो रिडाइरेक्ट अनुसन्धान यही भिन्नतामा चुक्छन्।

IPv4 र IPv6 ले यसलाई फरक तरिकाले पुर्याउँछन्

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

नीतिका सेटिङ पनि छुट्टै छन्, त्यसैले होस्टले IPv4 रिडाइरेक्ट स्वीकारेर IPv6 बेवास्ता गर्न सक्छ, वा उल्टो।

विचाराधीन प्रवाहले दुवैमध्ये कुनै पनि प्रयोग गर्न सक्छ भने दुवै परिवार जाँच्नुहोस्।

स्वीकार होस्टको नीति हो, सञ्जालको तथ्य होइन

Linux मा रिडाइरेक्ट स्वीकार इन्टरफेसअनुसार र विश्वव्यापी रूपमा नियन्त्रित हुन्छ, र पूर्वनिर्धारित मान होस्ट र राउटर भूमिकामा फरक पर्छ। रिडाइरेक्ट स्वीकार गर्ने सुरुङ इन्टरफेस अनौठो डिजाइन हो, किनकि पोइन्ट-टु-पोइन्ट सुरुङभित्र एउटै लिङ्कको वैकल्पिक अर्को हपको कुनै अर्थ हुँदैन। त्यसैले यो सेटिङ अनुमान गर्नुभन्दा पढ्न लायक छ।

सुरक्षित रिडाइरेक्ट सेटिङले कुन गेटवेलाई विश्वास गर्न सकिन्छ भन्ने अझ सीमित गर्छ।

तपाईंले होस्ट कडा बनाउँदै हुनुहुन्छ भने समीक्षा गर्नुपर्ने सेटिङ यिनै हुन्, र एउटै सञ्जालका दुई मेसिन फरक व्यवहार गर्नुको कारण पनि यिनै हुन्। तिनलाई डिबगिङको छोटो बाटो होइन, नीतिका रूपमा बदल्नुहोस्।

रिडाइरेक्टले व्याख्या गर्न नसक्ने कुरा

विशिष्ट रुट, नीतिगत रुटिङ नियम र स्थानीय इन्टरफेसले रिडाइरेक्ट बिनै धेरैजसो अप्रत्याशित मार्ग व्याख्या गर्छन्। अझ विशिष्ट प्रिफिक्स, स्रोत ठेगानासँग मिल्ने नियम, वा अर्को तालिकामा दोस्रो पूर्वनिर्धारित मार्ग यीमध्ये प्रत्येकले तपाईंले अपेक्षा गरेको रुटलाई ओभरराइड गर्छ। तिनलाई पहिले जाँच्नुहोस्, किनकि ती निर्धारक र देखिने छन्।

पुरानो क्याप्चर अर्को पासो हो, किनकि सञ्जाल बदलेको क्लाइन्टको स्थानीय गेटवे फरक हुन्छ।

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

सुरुङलाई दोष दिनुअघि रुट जाँच्नुहोस्

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

संरक्षित मार्ग चुपचाप असंरक्षित हुनुको कारण रिडाइरेक्ट कहिल्यै हुनुहुँदैन, त्यसैले स्वीकार नीति डिजाइन समीक्षामा पर्छ। RFC 792 परिभाषा IPv4 सन्देशले के भन्न सक्छ भन्ने सन्दर्भ बनिरहन्छ।

रुट खोजीको नतिजा र क्याप्चरको समय सँगै लेख्नुहोस्, अनि अर्को व्यक्तिले तपाईंको निष्कर्ष दोहोर्याउन सक्छ।