ESP ठीक से डिक्रिप्ट करता है और अंदर का पैकेट फिर भी कहीं नहीं जाता

ESP रिसीव काउंटर बढ़ता है, टनल बनी रहती है, और ऐप्लिकेशन को पैकेट कभी नहीं दिखता। डिक्रिप्शन हुआ, इंटीग्रिटी जाँच पास हुई, और फिर रिसीवर को तय करना था कि सुरक्षित पेलोड असल में क्या है। उसी आखिरी कदम पर फॉर्मेट की असंगति सामने आती है, और बाहर से देखने पर यह फायरवॉल की समस्या जैसा बिलकुल नहीं लगता।

जब लेबल झूठ बोले तो क्या दिखता है

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

बढ़ता रिसीव काउंटर वाकई अच्छी खबर है: पैकेट आ रहे हैं और प्रमाणित हो रहे हैं। यह सबूत नहीं है कि अंदर का पैकेट क्रिप्टो परत के ऊपर किसी चीज़ के लिए अर्थपूर्ण था।

टाइप ट्रेलर में रहता है

सामान्य IPsec टनल मोड में, ESP से सुरक्षित पेलोड में एक पूरा अंदरूनी IP पैकेट होता है। ट्रेलर का अगला हेडर फ़ील्ड तय करता है कि वह पेलोड क्या है, और यह न TCP पोर्ट है, न बाहरी हेडर में प्रोटोकॉल नंबर, और न ही शुरुआती SPI और क्रम-संख्या फ़ील्ड का हिस्सा। RFC 4303 अनुभाग 2.6 इसे पेलोड-टाइप फ़ील्ड के रूप में परिभाषित करता है, जो सटीक काम के लिए सटीक नाम है।

जिन मानों से आप मिलेंगे वे छोटे हैं और याद रखने योग्य हैं: IPv4 4 है (0x04) और IPv6 41 है (0x29)।

ये संख्याएँ स्थानीय परंपरा से नहीं, IANA के प्रोटोकॉल नंबर आवंटन से आती हैं। जो प्रेषक IPv4 घोषित करता है पर IPv6 पैकेट लपेटता है, उसने फॉर्मेट की असंगति पैदा की है, और अपने ही लेबल के विरुद्ध जाते बाइटों को कोई फायरवॉल नियम ठीक नहीं करता।

सामान्य संदिग्धों से इसे कैसे अलग करें

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

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

अगर कोई वह सबूत नहीं दे सकता, तो आपके पास फॉर्मेट बग नहीं है। आपके पास एक सिद्धांत है, और सिलेक्टर ही बेहतर दाँव हैं।

मरम्मत क्या नहीं है

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

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

प्रवाह जाँचें, काउंटर नहीं

सुधार के बाद असली IPv6 प्रवाह को शुरू से अंत तक जाँचें: टनल से होकर एक ऐप्लिकेशन अनुरोध, उसका उत्तर, और वह पता-युग्म जो हर पक्ष देखता है। बढ़ता ESP काउंटर केवल यह साबित करता है कि पैकेट प्राप्त और प्रमाणित हो रहे हैं। यह नहीं बताता कि अंदर का पैकेट उपयोगी था या नहीं।

दोनों नतीजे टिकट में दर्ज करें। काउंटर की गति के साथ चलता प्रवाह मरम्मत है; अकेले काउंटर की गति ठीक वही है जो आपके पास शुरू करने से पहले थी।