ESP पहुँच गया पर कुछ भी डिक्रिप्ट नहीं हुआ? इनबाउंड चरणों का पालन करें

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

आगमन एक अवलोकन है, तीन नहीं

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

यही अंतर एक सामान्य रिपोर्ट को समझाता है: एक पक्ष का एन्क्रिप्शन काउंटर बढ़ता है जबकि दूसरा कोई उपयोगी डिक्रिप्टेड ट्रैफ़िक नहीं बताता. दोनों कथन एक साथ सत्य हो सकते हैं, क्योंकि वे एक ही प्रयास के अलग चरणों का वर्णन करते हैं।

एसोसिएशन की खोज डिक्रिप्शन से पहले होती है

रिसीवर ज़रूरत पड़ने पर फ़्रैगमेंट फिर जोड़ता है, फिर पैकेट के लिए सुरक्षा एसोसिएशन ढूँढता है। सामान्य यूनिकास्ट में SPI और गंतव्य इसे चुनते हैं। वैध एसोसिएशन न हो तो आगे कोई प्रसंस्करण नहीं होता, इसलिए पुराना या बेमेल SPI एप्लिकेशन को दिखने वाली त्रुटि के बजाय चुप्पी पैदा करता है।

एसोसिएशन दिशात्मक होते हैं और कुंजी नवीनीकरण के दौरान बदल सकते हैं, इसलिए रिसीविंग पीयर, SPI और समय-चिह्न को उस इनबाउंड एसोसिएशन के पास दर्ज करें जिसे आप वर्तमान मानते हैं। दिखाया गया आउटबाउंड एसोसिएशन या स्वस्थ IKE संबंध उस एसोसिएशन का विकल्प नहीं है जिसे यह पैकेट प्राप्त करना चाहिए।

रीप्ले और इंटीग्रिटी जाँच पेलोड बनने से पहले ही अस्वीकार करती हैं

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

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

UDP पोर्ट 4500 एक पात्र है, फ़ैसला नहीं

NAT ट्रैवर्सल ESP को UDP के अंदर ले जाता है, और वही पोर्ट IKE तथा कीपअलाइव संदेश भी ले जाता है। इसलिए 4500 पर गतिविधि कहती है कि कुछ पोर्ट का उपयोग कर रहा है, यह नहीं कि एप्लिकेशन ने ESP पैकेट बनाया। डेटा ट्रैफ़िक के लिए इसे जोड़ने से पहले पेलोड का वर्गीकरण करें।

यह तब मायने रखता है जब कैप्चर ही एकमात्र उपलब्ध प्रमाण हो। समय पर आने वाला कीपअलाइव संदेश मृत टनल को जीवित दिखा सकता है, और IKE संदेश कैप्चर को डेटा पथ से अधिक व्यस्त दिखा सकता है।

निष्कर्षण के बाद ही राउटिंग और नीति लागू होती हैं

जब डिक्रिप्शन सफल होता है, पुनःप्राप्त अंदरूनी पैकेट सामान्य पथ में प्रवेश करता है: नीति जाँच, राउटिंग, फ़ॉरवर्डिंग नियम और गंतव्य होस्ट। एक पैकेट सभी सुरक्षा जाँच पार करके भी यहाँ गिराया जा सकता है, और उत्तर पथ भी मौजूद होना चाहिए। वह विफलता फ़ॉरवर्डिंग की है, ESP की नहीं।

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

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