ICMP रीडायरेक्ट आणि तुमचे VPN मार्ग: प्रत्यक्षात काय बदलते

टनेलमधून जायला हवा असा प्रवाह दुसरा पुढील हॉप निवडतो, आणि कोणालातरी कॅप्चरमध्ये ICMP रीडायरेक्ट सापडतो। तो एक गृहीत आहे, निदान नाही। रीडायरेक्ट हा चांगल्या पुढील हॉपबद्दलचा राउटरचा सल्ला आहे, आणि होस्ट त्यानुसार कार्य करतो का, हे प्लॅटफॉर्म, इंटरफेस आणि पत्ता कुटुंबानुसार वेगळ्या असलेल्या सेटिंग्जवर अवलंबून आहे।

रीडायरेक्ट हा राउटरकडून आलेला सल्ला आहे

IPv4 ICMP रीडायरेक्टना स्वतःचा संदेश प्रकार आणि मर्यादित अटी असतात: राउटर पॅकेट ज्या इंटरफेसवरून आले त्याच इंटरफेसवरून पुढे पाठवतो, आणि त्याच लिंकवर गंतव्याच्या जवळचा पुढील हॉप त्याला माहीत असतो। मग तो प्रेषकाला तो हॉप थेट वापरण्यास सांगतो। संदेशात नवीन गेटवेचे नाव असते आणि प्रेषकाला तो प्रवाहाशी जुळवता यावा म्हणून मूळ पॅकेटचा काही भाग समाविष्ट असतो। हा स्थानिक टोपोलॉजीबद्दलचा सौजन्यपूर्ण संदेश आहे, आणि प्रेषक सुचवलेल्या गेटवेसोबत त्याच लिंकवर आहे असे तो गृहीत धरतो।

प्रेषकाला तो दुर्लक्षित करण्याचे स्वातंत्र्य आहे। प्रोटोकॉल होस्टला टेबल बदलण्यास भाग पाडत नाही, आणि कॅप्चर केलेला रीडायरेक्ट फक्त राउटरने तो पाठवला एवढेच सिद्ध करतो।

बहुतेक रीडायरेक्ट तपासण्या याच फरकामुळे चुकतात।

IPv4 आणि IPv6 तो वेगळ्या पद्धतीने पोहोचवतात

IPv6 मध्ये समांतर यंत्रणा ICMPv4 मध्ये नसून शेजारी शोधात असते, संदेश स्वरूप आणि पडताळणी नियम वेगळे असतात। संकल्पना जुळतात, पॅकेट जुळत नाहीत। ICMP प्रकार 5 साठी लिहिलेला कॅप्चर फिल्टर IPv6 नेटवर्कवर काहीही दाखवणार नाही, आणि त्याचा अर्थ कधीकधी रीडायरेक्ट झाला नाही असा पुरावा असा लावला जातो।

धोरणात्मक सेटिंग्जही वेगळ्या आहेत, त्यामुळे होस्ट IPv4 रीडायरेक्ट स्वीकारून IPv6 दुर्लक्षित करू शकतो, किंवा उलट।

विचाराधीन प्रवाह दोन्हींपैकी कोणताही वापरू शकत असेल तर दोन्ही कुटुंबे तपासा।

स्वीकार हे होस्टचे धोरण आहे, नेटवर्कची वस्तुस्थिती नाही

Linux वर रीडायरेक्ट स्वीकार इंटरफेसनुसार आणि जागतिक पातळीवर नियंत्रित होतो, आणि डीफॉल्ट मूल्ये होस्ट आणि राउटर भूमिकांमध्ये वेगळी असतात। रीडायरेक्ट स्वीकारणारा टनेल इंटरफेस विचित्र रचना आहे, कारण पॉइंट-टू-पॉइंट टनेलमध्ये त्याच लिंकवरील पर्यायी पुढील हॉपला अर्थ नाही। म्हणून हे सेटिंग गृहीत धरण्यापेक्षा वाचण्यासारखे आहे।

सुरक्षित रीडायरेक्ट सेटिंग्ज कोणत्या गेटवेवर विश्वास ठेवता येईल हे आणखी मर्यादित करतात।

तुम्ही होस्ट कडक करत असाल, तर तपासायची सेटिंग्ज हीच आहेत, आणि एकाच नेटवर्कवरील दोन मशिना वेगळ्या पद्धतीने वागण्याचे कारणही हेच आहे। ती डीबगिंगची शॉर्टकट म्हणून नाही, धोरण म्हणून बदला।

रीडायरेक्ट काय स्पष्ट करू शकत नाही

विशिष्ट मार्ग, धोरणात्मक राउटिंग नियम आणि स्थानिक इंटरफेस हे रीडायरेक्टशिवायही बहुतेक अनपेक्षित मार्ग स्पष्ट करतात। अधिक विशिष्ट उपसर्ग, स्रोत पत्त्याशी जुळणारा नियम, किंवा दुसऱ्या टेबलमधील दुसरा डीफॉल्ट यापैकी प्रत्येकजण तुम्ही अपेक्षित असलेल्या मार्गावर मात करेल। ते आधी तपासा, कारण ते निर्धारक आणि दृश्य आहेत।

जुने कॅप्चर हा दुसरा सापळा आहे, कारण नेटवर्क बदललेल्या क्लायंटचा स्थानिक गेटवे वेगळा असतो।

पूर्वीच्या जोडणीतील जुना रीडायरेक्ट सध्याच्या मार्गाबद्दल काहीही स्पष्ट करत नाही, म्हणून आता नियंत्रण रहदारी कोणता इंटरफेस घेतो ते नोंदवा।

टनेलला दोष देण्यापूर्वी मार्ग तपासा

गंतव्यासाठी कोणता मार्ग वापरेल असे कर्नेलला विचारा, नंतर तो तुम्ही हेतू असलेल्या टेबलशी तुलना करा। उत्तर टेबलशी जुळले तर रीडायरेक्टने काहीही बदलले नाही आणि तपासणी इतरत्रची आहे। जुळले नाही तर टनेलच चुकीचा असे गृहीत धरण्यापूर्वी कॅशे झालेला रीडायरेक्ट, धोरण नियम किंवा दुसरे टेबल शोधा। मार्ग शोध हाच खरा आधार आहे, बाकी सर्व तो असा कसा झाला याची गोष्ट आहे।

संरक्षित मार्ग गुपचूप असंरक्षित होण्याचे कारण रीडायरेक्ट कधीही असू नये, म्हणून स्वीकार धोरण रचना आढाव्यात असले पाहिजे। RFC 792 व्याख्या हा IPv4 संदेश काय सांगू शकतो यासाठीचा संदर्भ राहतो।

मार्ग शोधाचा निकाल आणि कॅप्चरची वेळ एकत्र लिहा, मग पुढच्या व्यक्तीला तुमचा निष्कर्ष पुन्हा तयार करता येईल।