ESP ले राम्ररी डिक्रिप्ट गर्छ र भित्री प्याकेट अझै कतै जाँदैन

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

लेबल झुटो बोल्दा के देखिन्छ

क्लाइन्ट लगमा यसलाई राउटिङ कालो प्वालबाट छुट्याउने केही छैन। दुवैले स्वस्थ टनेलको छेउमा एप्लिकेसन टाइमआउट उत्पन्न गर्छन्, त्यसैले पहिले काउन्टरलाई दोष दिइन्छ।

बढिरहेको प्राप्ति काउन्टर साँच्चै राम्रो समाचार हो: प्याकेट आइरहेका छन् र प्रमाणित भइरहेका छन्। तर भित्री प्याकेट क्रिप्टो तहभन्दा माथिको कुनै कुराका लागि अर्थपूर्ण थियो भन्ने प्रमाण यो होइन।

प्रकार ट्रेलरमा बस्छ

सामान्य IPsec टनेल मोडमा, ESP ले संरक्षित गरेको पेलोडमा पूरा भित्री IP प्याकेट हुन्छ। ट्रेलरको अर्को हेडर फिल्डले त्यो पेलोड के हो भनेर निर्धारण गर्छ, र त्यो TCP पोर्ट होइन, बाहिरी हेडरको प्रोटोकल नम्बर होइन, र सुरुको SPI तथा क्रम-नम्बर फिल्डको भाग पनि होइन। RFC 4303 खण्ड 2.6 ले यसलाई पेलोड-प्रकार फिल्डका रूपमा परिभाषित गर्छ, जुन ठ्याक्कै कामका लागि ठ्याक्कै नाम हो।

तपाईंले भेट्ने मानहरू साना छन् र सम्झनलायक छन्: IPv4 भनेको 4 (0x04) र IPv6 भनेको 41 (0x29) हो।

ती सङ्ख्याहरू स्थानीय परम्पराबाट होइन, IANA को प्रोटोकल नम्बर बाँडफाँटबाट आउँछन्। IPv4 घोषणा गरेर पनि IPv6 प्याकेट बेर्ने प्रेषकले ढाँचाको असङ्गति उत्पन्न गरेको छ, र आफ्नै लेबलविरुद्ध जाने बाइटहरू कुनै फायरवाल नियमले सुधार्दैन।

सामान्य शङ्कास्पदहरूबाट यसलाई कसरी छुट्याउने

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

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

यदि कोही पनि त्यो प्रमाण दिन सक्दैन भने तपाईंसँग ढाँचाको बग छैन। तपाईंसँग एउटा सिद्धान्त छ, र सिलेक्टरहरू नै अझ राम्रो दाउ हुन्।

मर्मत के होइन

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

यदि पुष्टि भएको असङ्गति सहकर्मी इम्प्लिमेन्टेसनबाट आएको हो भने, न्यूनतम सफा पुनरुत्पादन राख्नुहोस् र त्यसलाई त्यो इम्प्लिमेन्टेसनको समर्थित च्यानलमा लैजानुहोस्।

प्रवाह जाँच्नुहोस्, काउन्टर होइन

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

दुवै नतिजा टिकटमा लेख्नुहोस्। काउन्टरको चलनसँगै काम गर्ने प्रवाह भए त्यो मर्मत हो; काउन्टरको चलन मात्र भनेको सुरु गर्नुअघि तपाईंसँग जे थियो त्यही हो।