ESP आयो तर केही पनि डिक्रिप्ट भएन? इनबाउन्ड चरणहरू पछ्याउनुहोस्
प्राप्ति, सुरक्षा प्रशोधन र फर्वार्डिङ तीन फरक नतिजा हुन्। कुनै पनि पहुँच नियम फराकिलो बनाउनुअघि कुन चरणले प्याकेट छोड्यो पहिचान गर्नुहोस्।
फायरवालको इन्क्रिप्शन काउन्टर बढ्दै जाँदा टनेलले केही पनि नपुर्याउँदा पहुँच नियम फराकिलो बनाउने प्रवृत्ति आउँछ। त्यो प्रवृत्तिले प्राप्तकर्ताको आफ्नै जाँच क्रम छोड्छ। इनबाउन्ड ESP प्याकेट धेरै चरणबाट जान्छ, र प्रत्येक चरणले फरक कारणले प्याकेटको जीवन अन्त्य गर्न सक्छ: मिल्ने एसोसिएसन छैन, रिप्ले वा इन्टिग्रिटी असफलता, वा भित्री प्याकेट ठीक छ तर अगाडि अनुमति छैन। असफल भएको चरणको नाम दिनुले IPsec बिग्रिएको भन्ने अस्पष्ट कथनलाई विशिष्ट काउन्टर र विशिष्ट सुधारमा बदल्छ।
आगमन एक अवलोकन हो, तीन होइन
ESP गेटवेमा पुग्छ भनी देखाउने बाहिरी क्याप्चरले बाहिरी प्याकेट आयो भन्ने मात्र प्रमाणित गर्छ। स्वीकृति भन्नाले प्राप्तकर्ताले एसोसिएसन भेट्टायो र प्याकेट प्रमाणित गर्यो। डेलिभरी भन्नाले पुनःप्राप्त भित्री प्याकेट आफ्नो गन्तव्यमा रुट भयो र जवाफ पायो। यी छुट्टाछुट्टै नतिजा हुन्, र तिनलाई मिलाएर देखाउने ड्यासबोर्डले तपाईंलाई चाहिने जानकारी नै लुकाउँछ।
त्यही भिन्नताले एउटा सामान्य प्रतिवेदन बुझाउँछ: एक पक्षको इन्क्रिप्शन काउन्टर बढ्छ जबकि अर्को पक्षले कुनै उपयोगी डिक्रिप्ट भएको ट्राफिक रिपोर्ट गर्दैन. दुवै कथन एकै समयमा सत्य हुन सक्छन्, किनकि तिनले एउटै प्रयासका फरक चरणहरू वर्णन गर्छन्।
एसोसिएसन खोजी डिक्रिप्शन अघि हुन्छ
प्राप्तकर्ताले आवश्यक परे टुक्राहरू पुनः जोड्छ, त्यसपछि प्याकेटको सुरक्षा एसोसिएसन भेट्टाउँछ। सामान्य युनिकास्टमा SPI र गन्तव्यले त्यो छान्छन्। वैध एसोसिएसन नभएमा थप प्रशोधन हुँदैन, त्यसैले पुरानो वा नमिल्ने SPI ले एप्लिकेसनले देख्ने त्रुटिको सट्टा मौनता उत्पन्न गर्छ।
एसोसिएसनहरू दिशामुखी हुन्छन् र कुञ्जी नवीकरणमा बदलिन सक्छन्, त्यसैले तपाईंले हालको मान्नुभएको इनबाउन्ड एसोसिएसनको छेउमा प्राप्तकर्ता पक्ष, SPI र समय-छाप लेख्नुहोस्। देखाइएको आउटबाउन्ड एसोसिएसन वा स्वस्थ IKE सम्बन्धले यो प्याकेट प्राप्त गर्नुपर्ने एसोसिएसनको विकल्प दिँदैन।
रिप्ले र इन्टिग्रिटी जाँचहरू पेलोड बन्नुअघि नै अस्वीकार गर्छन्
एसोसिएसन भेटिएपछि प्राप्तकर्ताले त्यसले तोकेका एल्गोरिदम लागू गर्छ। एन्टी-रिप्ले सक्षम भएमा विन्डो बाहिरको क्रम संख्या अस्वीकार हुन्छ। इन्टिग्रिटी जाँच असफल भएमा पनि प्रशोधन अन्त्य हुन्छ, किनकि ICV प्राप्त भएको प्याकेटसँग मिल्दैन। कुनै पनि अवस्थामा डिक्रिप्ट भएको भित्री प्याकेट बन्दैन, त्यसैले केही पनि रुटिङ, नीति वा एप्लिकेसनमा पुग्दैन।
यी अवस्थाका लागि कार्यान्वयनका अभिलेखित त्रुटि र काउन्टर प्रयोग गर्नुहोस्, हरेक प्राप्ति असफलतालाई पहुँच-सूची अस्वीकृति मान्नुको सट्टा। ट्राफिक देखियोस् भनेर इन्टिग्रिटी वा रिप्ले सुरक्षा बन्द गर्नुले आएको प्याकेट वैध थियो भन्ने प्रमाणित गर्दैन; यसले सत्य बताइरहेको जाँच हटाउँछ।
UDP पोर्ट 4500 एउटा भाँडो हो, फैसला होइन
NAT ट्राभर्सलले ESP लाई UDP भित्र बोक्छ, र त्यही पोर्टले IKE तथा किपअलाइभ सन्देश पनि बोक्छ। त्यसैले 4500 मा गतिविधि भन्नाले कुनै कुरा पोर्ट प्रयोग गर्दैछ, एप्लिकेसनले ESP प्याकेट बनायो भन्ने होइन। डेटा ट्राफिकमा जोड्नुअघि पेलोडको वर्गीकरण गर्नुहोस्।
क्याप्चर नै एकमात्र उपलब्ध प्रमाण हुँदा यो महत्त्वपूर्ण हुन्छ। समयमै आउने किपअलाइभ सन्देशले मृत टनेललाई जीवित देखाउन सक्छ, र IKE सन्देशले क्याप्चरलाई वास्तविक डेटा मार्गभन्दा व्यस्त देखाउन सक्छ।
निकासीपछि मात्र रुटिङ र नीति लागू हुन्छन्
डिक्रिप्शन सफल भएपछि पुनःप्राप्त भित्री प्याकेट सामान्य मार्गमा प्रवेश गर्छ: नीति जाँच, रुटिङ, फर्वार्डिङ नियम र गन्तव्य होस्ट। प्याकेटले सबै सुरक्षा जाँच पार गरे पनि यहाँ छोडिन सक्छ, र जवाफ मार्ग पनि हुनुपर्छ। त्यो असफलता फर्वार्डिङको हो, ESPको होइन।
काउन्टरहरूलाई तिनका अभिलेखित चरणसँग बाँधेर राख्नुहोस्। इन्टरफेस प्राप्ति, स्वीकृत ESP, डिक्रिप्ट भएका बाइट र फर्वार्ड गरिएका भित्री प्याकेट एउटै संख्या हुनुपर्ने छैन, विशेषगरी जब त्वरित मार्गले डेटा प्लेन सम्हाल्छ र नियन्त्रण प्लेन छुट्टै रिपोर्ट गर्छ। सामान्य ड्यासबोर्ड लेबल दुई काउन्टरले एउटै कुरा जनाउँछन् भन्ने प्रमाण होइन।
एउटा नयाँ अधिकृत कार्यका लागि अन्तिम पुष्टि भएको सीमा र पहिलो सान्दर्भिक त्रुटि राख्नुहोस्। त्यो जोडीले अर्को प्रशासकलाई के छानबिन गर्ने भनी बताउँछ: यातायात डेलिभरी, एसोसिएसन र इन्टिग्रिटी, वा सामान्य भित्री फर्वार्डिङ, र संख्या सार्न हरेक नियम खुकुलो बनाउने चलनको सुधारबाट बचाउँछ।