जब IPsec खस्छ, तब बैकअप मार्ग बैकअप नीति होइन

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

राउटिङ तालिकामा उस्तै देखिने दुई नतिजा

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

त्यसैले गडबडीको मार्ग कसैले अनुमति प्राप्त नतिजामध्ये कुन लागू हुन्छ निर्णय गरेपछि मात्र डिजाइन बन्छ। त्यो निर्णय नभएसम्म बैकअप मार्ग योजना होइन, प्रलोभन हो।

नीति मोडेलमा दुई होइन, तीन निर्णय छन्

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

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

आफ्नो प्रवाहको आवश्यकता तीनमध्ये एउटा वाक्यका रूपमा लेख्नुहोस्: सुरक्षित मार्ग नबनेसम्म रोकिनुहोस्, अर्को सुरक्षित मार्गमा जानुहोस्, वा IPsec बिना चल्न छुट्टै अनुमति पाएको मार्ग प्रयोग गर्नुहोस्। तेस्रोले मात्र सुरक्षा सम्झौता बदल्छ, र त्यसलाई हस्ताक्षर गर्न सक्ने मालिक चाहिन्छ। त्यो वाक्य परिवर्तन अभिलेखमा जान्छ, कसैको सम्झनामा होइन। समीक्षकहरू दोस्रो वाक्यलाई स्वीकृति दिन्छन् र तेस्रोलाई अस्वीकार गर्छन्, र दुवै निर्णय देखिने भएमा उचित हुन्।

बाइपास दुवै छेउले हस्ताक्षर गर्ने सम्झौता हो

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

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

बैकअप चल्नका लागि चयनक हटाउनु वा नक्सा ढिलो गर्नु नियन्त्रित छुट होइन। यसले छुटको दायरा फराकिलो बनाउँछ, टाढाको छेउलाई अरू केही लागू गराइराख्छ, र प्रवाहसँग कुन अनुवाद नियम मिल्छ परिवर्तन गर्न सक्छ।

अनुवाद र प्रवेशले गणना बदल्छन्

अनुवादले ठेगानाको अर्को दृश्य दिन सक्छ, तर अगाडि र पछाडिको म्यापिङ वैकल्पिक मार्गसँग मिल्नुपर्छ। एकतर्फी म्यापिङले खुल्ने र त्यसपछि झुन्डिने जडान बनाउँछ। आधा म्यापिङ केही नहुनुभन्दा नराम्रो हो, किनकि यो प्रगति जस्तो देखिन्छ।

प्रवेश दोस्रो आधा हो। प्राप्त गर्ने पक्षसँग यो ट्राफिकका लागि स्पष्ट नियम, आफ्नै लगिङ, र राति तीन बजे स्वीकृत छुट र गल्ती छुट्याउने तरिका हुनुपर्छ।

पुनर्स्थापना डिजाइनको भाग हो

गडबडी कसरी पत्ता लाग्छ, कुन नीतिले प्रतिस्थापन छान्छ, र त्यो हुँदा चलिरहेका सत्रलाई के हुन्छ अभिलेख गर्नुहोस्। नयाँ जडान परिवर्तनपछि सफल हुन सक्छ, जबकि पुरानो अब लागू नहुने ठेगानासँग बाँधिएको अवस्था राख्छ।

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

गडबडी मात्र होइन, दुवै अवस्था जाँच्नुहोस्

स्वीकृतिले असफल सुरुङको अवस्था र पुनर्स्थापित अवस्था दुवै समेट्छ, प्रत्येकमा अनुप्रयोग जाँचसहित। रोचक नतिजा प्याकेट चलिरहनु होइन, तर तिनीहरू संस्थाले छानेको सम्झौता अन्तर्गत मात्र चलेको हो।

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