दुई /24 को साटो एउटा /23: वार्तामा के फेरिन्छ

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

मानिसहरूले एउटैमा मिलाउने तीन तथ्य

ठेगानाको सेटले कुन होस्टहरू सुरक्षित गर्नुपर्ने हो भन्छ। समूहीकरणले ती ठेगानाहरू कसरी प्रस्ताव गरिन्छ भन्छ: एउटा सेलुक्टर वा धेरै, एउटा संस्थामा वा धेरैमा। वार्तामा तय भएको नतिजाले दुई पक्षले वास्तवमै के स्थापित गरे भन्छ, र त्यो पहिलो दुईमध्ये कुनैभन्दा साँघुरो हुन सक्छ।

परिवर्तनको अभिलेखमा तिनलाई छुट्टाछुट्टै लेख्नुहोस्। कन्फिगरेसनको एउटा लाइनले प्रायः तीन फरक उत्तर लुकाउँछ। तिनलाई छुट्याउन नसक्ने समीक्षकले परिवर्तन पनि स्वीकृत गर्न सक्दैन।

उत्तरदाताले तपाईंको एकत्रीकरणसँग के गर्न पाउँछ

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

केही नस्वीकार्ने उत्तरदाताले त्यसको साटो त्रुटि फर्काउँछ, जसले कम्तीमा प्रस्ताव अस्वीकार गरिएको हो भन्छ, चुपचाप साँघुरो गरिएको होइन।

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

सारांशले चुपचाप सीमा कहाँ मेट्छ

दुई /24 मा फरक सेवा नियम हुन सक्छन्: एउटाले मात्र व्यवस्थापन प्रोटोकल अनुमति दिन सक्छ, अर्कोले सामान्य अनुप्रयोग। IP तहमा दुवै ठेगाना ढाक्ने सेलुक्टरले ती नियम जोगाउँदैन, र सारांशले सीमालाई सुरुङको पछाडि भएको फिल्टरिङमा सार्छ। एकत्रीकरण गर्नुअघि प्रत्येक सबनेटको सेवा नियम सूचीबद्ध गर्नुहोस्, नत्र त्यो तुलना कहिल्यै हुँदैन।

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

नतिजा प्रत्येक प्रिफिक्सअनुसार पढ्ने

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

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

परिवर्तनलाई फर्काउन सकिने बनाउने

नयाँ नीति प्रत्येक प्रिफिक्स संयोजनबाट परीक्षण नगरुन्जेल पुरानो नीति कन्फिगरेसनमा राख्नुहोस्, र प्रत्येक प्रवाह कुन संस्थामा पुग्यो टिप्नुहोस्। प्रस्ताव फेरिँदा पक्षले संस्था फेर्छ भने, फिर्ताले पुराना ठेगाना मात्र होइन, पुरानो प्रस्ताव पनि पुनर्स्थापित गर्नुपर्छ।

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