के दुई IPsec साथीहरूबीचको राउटरलाई IPsec चाहिन्छ?

प्रयोगशाला अभ्यास जसले “दुई साइटबीच IPsec कन्फिगर गर्नुहोस्” भन्छ, दुई फरक काम लुकाउँछ। दुवै छेउले टनेल अन्त्य गर्छन्: तिनीहरू वार्ता गर्छन्, प्रमाणित गर्छन्, इन्क्रिप्ट र डिक्रिप्ट गर्छन्। बीचको कुनै पनि राउटर यस्ता प्याकेट अगाडि पठाउँछ जसको बाह्य हेडर छेउहरूको हुन्छ, र यो टनेल रहेको जानकारीबिना गर्छ।

कुनै उपकरणबाट कुन काम मागिएको छ भनी निर्धारण गर्नु अभ्यासको पहिलो कदम हो। प्रयोगशाला प्रतिवेदनहरूमा अधिकांश अलमल, र उत्पादन रेखाचित्रमा धेरै अलमल, “IPsec समर्थन गर्छ” लाई दुईको सट्टा एउटा गुण मान्नबाट आउँछ।

अग्रेषण समाप्ति होइन

टनेल मोडमा बाह्य IP हेडर टनेल अन्त्य गर्ने उपकरणहरूलाई सम्बोधित हुन्छ। बीचको राउटरले गन्तव्य खोजेर अगाडि पठाउँछ, अरू कुनै पनि प्याकेटजस्तै, र यसले बोक्ने पेलोड यसका लागि अपारदर्शी हुन्छ।

यो अपारदर्शिता जानाजान हो। राउटरसँग साथीको रहस्य हुँदैन, यसले कुनै वार्ता गर्दैन र यसलाई नीति डेटाबेस आवश्यक पर्दैन। यसलाई टाढाको छेउसम्म मार्ग र प्याकेट अगाडि पठाउने अनुमति चाहिन्छ।

दुवैलाई मिसाउँदा वास्तविक गल्ती हुन्छन्: ट्रान्जिट फायरवाललाई “IPsec अनुमति देऊ” भन्नु, जबकि वास्तविक आवश्यकता विशिष्ट ठेगानाहरूबीच प्रोटोकल 50 लाई अनुमति दिनु हो, वा बीचको उपकरणले निरीक्षणका लागि डिक्रिप्ट गर्छ भन्ने अपेक्षा गर्नु, जबकि यससँग कुनै कुञ्जी छैन।

बीचको उपकरणले जे भए पनि के सही गर्नुपर्छ

अग्रेषणका आफ्नै आवश्यकताहरू छन्। मार्गहरूले दुवै बाह्य छेउसम्म पुग्नुपर्छ, र बाटोको हरेक नीतिले अनुमानित पोर्ट नम्बरको सट्टा वास्तविक बाह्य ट्राफिकलाई अनुमति दिनुपर्छ। TCP 443 विरुद्ध लेखिएको नियम, किनभने कसैले TLS माने, प्रोटोकल 50 सँग मिल्ने छैन।

मूल ESP IP प्रोटोकल 50 हो। यो TCP 50 होइन र UDP 50 होइन, र गैर-TCP ट्राफिक रोक्ने नियमले यसलाई खसाल्छ। यदि डिजाइनले UDP इन्क्याप्सुलेसन प्रयोग गर्छ भने, देखिने यातायात इन्क्याप्सुलेसन पोर्टमा सर्छ, र नीतिले छानिएको डिजाइनसँग मिल्नुपर्छ।

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

सिमुलेटरले प्रश्न किन बदल्छ

सिमुलेटर छोटो सुविधा-सूची भएको राउटर होइन; यो एउटा मोडेल हो जसको कागजात गरिएको उपसमूह र कुनै उपकरणलाई के गर्न कन्फिगर गर्न सकिन्छ भन्ने आफ्नै नियमहरू छन्। Cisco का Packet Tracer सामान्य प्रश्नहरूले उपकरण र प्रोटोकलहरू सरलीकृत मोडेल हुन् भनी स्पष्ट भन्छन्।

त्यसैले प्रश्न तीन प्रश्न बन्छ। अनुकरण गरिएको उपकरणले परिदृश्यलाई चाहिने प्याकेट अगाडि पठाउँछ? त्यही उपकरणले पाठले मानेको कन्फिगरेसन सतह दिन्छ? र स्वीकृत आदेशको अर्थ व्यवहार साँच्चै अनुकरण गरिन्छ, वा मात्र विश्लेषण गरिन्छ?

अनुपस्थित आदेश तपाईंको कन्फिगरेसनको गल्ती नभई मोडेलको सीमा हुन सक्छ। उपस्थित आदेशले हरेक उत्पादन व्यवहार दोहोर्याउनुबिना वाक्यरचना स्वीकार गर्न सक्छ। कुनै पनि दिशामा निष्कर्ष निकाल्नुअघि स्थापित संस्करणको उपकरण सहायता हेर्नुहोस्।

प्रयोगशालाका लागि उत्तीर्णता सर्त लेख्ने

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

IPsec पाठका लागि वार्ताको स्थिति र LAN देखि LAN सम्म एक संरक्षित प्रवाह थप्नुहोस्। यदि सिमुलेटरले सुरक्षा सम्बद्धता देखाउँछ भने ती अभिलेख गर्नुहोस्। नदेखाए टनेल प्रमाणित भयो भन्ने सङ्केत दिनुको सट्टा प्रतिवेदनमा त्यो भन्नुहोस्।

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

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