ESP नीट डिक्रिप्ट करते आणि आतली पॅकेट तरीही कुठेही पोहोचत नाही
अॅपला काहीच दिसत नसताना ESP काउंटर वाढतात. ट्रेलरमधील पुढील हेडर आतल्या पॅकेटशी जुळले पाहिजे, ही सिलेक्टर चुकण्यापेक्षा वेगळी बिघाड आहे.
ESP रिसीव्ह काउंटर वाढतो, टनेल वरच राहते, आणि अॅप्लिकेशनला पॅकेट कधीच दिसत नाही. डिक्रिप्शन झाले, इंटिग्रिटी तपासणी पास झाली, आणि मग रिसीव्हरला ठरवायचे होते की संरक्षित पेलोड प्रत्यक्षात काय आहे. त्या शेवटच्या पायरीतच फॉरमॅटची विसंगती दिसते, आणि बाहेरून पाहिल्यास ती फायरवॉलच्या समस्येसारखी अजिबात वाटत नाही.
लेबल खोटे बोलते तेव्हा काय दिसते
क्लायंट लॉगमध्ये हे राउटिंग ब्लॅक होलपासून वेगळे करणारे काहीच नाही. दोन्ही निरोगी टनेलच्या शेजारी अॅप्लिकेशन टाइमआउट निर्माण करतात, म्हणूनच आधी काउंटरांना दोष दिला जातो.
वाढणारा रिसीव्ह काउंटर खरोखर चांगली बातमी आहे: पॅकेट येत आहेत आणि प्रमाणित होत आहेत. पण आतले पॅकेट क्रिप्टो थराच्या वरच्या कशालाही अर्थपूर्ण होते याचा हा पुरावा नाही.
प्रकार ट्रेलरमध्ये राहतो
नेहमीच्या IPsec टनेल मोडमध्ये, ESP ने संरक्षित केलेल्या पेलोडमध्ये पूर्ण आतले IP पॅकेट असते. ट्रेलरमधील पुढील हेडर फील्ड ते पेलोड काय आहे हे ठरवते, आणि ते TCP पोर्ट नाही, बाहेरील हेडरमधील प्रोटोकॉल क्रमांक नाही, आणि सुरुवातीच्या SPI व क्रम-क्रमांक फील्डचा भागही नाही. RFC 4303 विभाग 2.6 ते पेलोड-प्रकार फील्ड म्हणून परिभाषित करते, जे अचूक कामासाठी अचूक नाव आहे.
तुम्हाला भेटणारी मूल्ये लहान आहेत आणि लक्षात ठेवण्यासारखी आहेत: IPv4 म्हणजे 4 (0x04) आणि IPv6 म्हणजे 41 (0x29).
ती संख्या स्थानिक परंपरेतून नाही, IANA च्या प्रोटोकॉल क्रमांक वाटपांतून येतात. IPv4 जाहीर करूनही IPv6 पॅकेट गुंडाळणारा प्रेषक फॉरमॅटची विसंगती निर्माण करतो, आणि स्वतःच्या लेबलाविरुद्ध जाणाऱ्या बाइट्स कोणताही फायरवॉल नियम दुरुस्त करत नाही.
नेहमीच्या संशयितांपासून हे कसे वेगळे करावे
हरवलेली बहुतेक पॅकेट एन्कोडिंग दोष नसतात. आधी सिलेक्टर तपासा, कारण IPv6 प्रीफिक्स वगळणारा ट्रॅफिक सिलेक्टर काहीही एन्कॅप्स्युलेट होण्यापूर्वीच ट्रॅफिक टाकून देतो. नंतर राउटिंग, नंतर स्वीकारणाऱ्या होस्टवर स्थानिक फिल्टरिंग तपासा. हे वगळल्यावरच पेलोड-फॉरमॅटची विसंगती विश्वासार्ह स्पष्टीकरण बनते.
एन्क्रिप्टेड कॅप्चर हे ठरवणार नाही, कारण संरक्षित पुढील हेडर एन्क्रिप्टेड पेलोडच्या आत असते. तुम्हाला इम्प्लिमेंटेशन डायग्नोस्टिक्स किंवा समर्थित डिक्रिप्टेड निरीक्षण बिंदू हवा, आणि दोन्हींसाठी वापरण्यापूर्वी परवानगी लागते.
तो पुरावा कोणीही देऊ शकत नसेल, तर तुमच्याकडे फॉरमॅट बग नाही. तुमच्याकडे एक सिद्धांत आहे, आणि सिलेक्टरच पण जास्त चांगला आहे.
दुरुस्ती काय नाही
ट्रॅफिक जावे म्हणून इंटिग्रिटी तपासण्या बंद करू नका. मधल्या राउटरवर एन्क्रिप्टेड पॅकेट पुन्हा लिहू नका, कारण ते चालणार नाही आणि कॅप्चरमध्ये उपयुक्त दिसत असतानाही प्रवाह खराब होईल. पोर्ट ब्लॉक झाला आहे या सिद्धांतावर अॅप्लिकेशनसाठी जास्त रुंद फायरवॉल नियम उघडू नका. यापैकी काहीही लेबलच्या विसंगतीला स्पर्श करत नाही.
जर पुष्टी झालेली विसंगती सहकारी इम्प्लिमेंटेशनमधून आली असेल, तर किमान स्वच्छ पुनरुत्पादन ठेवा आणि ते त्या इम्प्लिमेंटेशनच्या समर्थित चॅनेलकडे न्या.
प्रवाह तपासा, काउंटर नाही
दुरुस्तीनंतर प्रत्यक्ष IPv6 प्रवाह सुरुवातीपासून शेवटपर्यंत तपासा: टनेलमधून अॅप्लिकेशन विनंती, तिचे उत्तर, आणि प्रत्येक बाजूला दिसणारी पत्त्यांची जोडी. वाढणारा ESP काउंटर फक्त पॅकेट स्वीकारले जात आहेत आणि प्रमाणित होत आहेत हे सिद्ध करतो. आतले पॅकेट वापरण्यायोग्य होते का याबद्दल तो काहीच सांगत नाही.
दोन्ही निकाल तिकिटात नोंदवा. काउंटरची हालचाल आणि चालणारा प्रवाह एकत्र असेल तर ती दुरुस्ती; फक्त काउंटरची हालचाल म्हणजे सुरू करण्यापूर्वी तुमच्याकडे जे होते तेच.