दोन /24 ऐवजी एक /23: वाटाघाटीत काय बदलते

दोन लगतचे /24 एका /23 मध्ये स्वच्छपणे विलीन होतात, आणि हे नीटनेटके गणित लोकांना बदल केवळ दृश्य आहे असे पटवते. हे पत्त्यांचे गणित आहे, आणि बोगद्याला सेलेक्टर महत्त्वाचे आहेत, जे नेटवर्कचे वर्णन नसून वाटाघाटीची ऑफर आहेत. लहान ओळ तोच रहदारी संरक्षित ठेवू शकते, अपेक्षेपेक्षा जास्त संरक्षित करू शकते किंवा त्यातील निम्मेही व्यापू शकत नाही, दोन्ही बाजू काय स्वीकारायला तयार आहेत यावर अवलंबून. स्थापित निकाल वाचणे हाच त्या तीनपैकी काय घडले हे जाणून घेण्याचा एकमेव मार्ग आहे.

लोक एकात जोडतात ती तीन तथ्ये

पत्त्यांचा संच सांगतो की कोणते होस्ट संरक्षित केले पाहिजेत. गटीकरण सांगते की ते पत्ते कसे ऑफर केले जातात: एक सेलेक्टर की अनेक, एका असोसिएशनमध्ये की अधिकात. वाटाघाटीतला निकाल सांगतो की दोन्ही बाजूंनी प्रत्यक्षात काय स्थापित केले, आणि तो पहिल्या दोनपैकी कोणत्याहीपेक्षा अरुंद असू शकतो.

बदलाच्या नोंदीत ते वेगवेगळे लिहा. कॉन्फिगरेशनची एक ओळ अनेकदा तीन वेगवेगळी उत्तरे लपवते. जो वेगळे करू शकत नाही तो पुनरावलोकनकर्ता बदलही मंजूर करू शकत नाही.

प्रतिसादकर्ता तुमच्या एकत्रीकरणासह काय करू शकतो

IKEv2 प्रतिसादकर्ता ऑफर केलेली सेलेक्टर जोडी आपण स्वीकारायला तयार असलेल्या उपसंचापर्यंत अरुंद करू शकतो, आणि स्वीकार्य काहीही नसल्यास ऑफर पूर्णपणे नाकारू शकतो. अतिरिक्त रहदारीस यात न बसता दुसरे असोसिएशन लागते असेही तो सूचित करू शकतो.

काहीही न स्वीकारणारा प्रतिसादकर्ता त्याऐवजी त्रुटी परत करतो, जी तरी ऑफर नाकारली गेली हे सांगते, शांतपणे अरुंद केली गेली नाही.

याचा अर्थ यशस्वी देवघेव सिद्ध करते की बाजू कशावर तरी सहमत झाल्या, तुम्ही सूचीबद्ध केलेल्या प्रत्येक गोष्टीवर सहमत झाल्या असे नाही. सुरुवातीचा यश संदेश निकाल वाचण्याचा प्रारंभबिंदू आहे, कधीही निष्कर्ष नाही. स्वीकारलेला उपसंच एका /24 पेक्षा लहान असू शकतो, त्यामुळे स्थापित संच ऑफरसारखा अजिबात दिसत नाही.

सारांश शांतपणे सीमा कुठे पुसतो

दोन /24 मध्ये वेगळे सेवा नियम असू शकतात: एक फक्त व्यवस्थापन प्रोटोकॉलला परवानगी देऊ शकतो, दुसरा सामान्य अनुप्रयोगाला. IP स्तरावर दोन्ही पत्ते व्यापणारा सेलेक्टर ते नियम जपत नाही, आणि सारांश सीमा बोगद्यामागील ज्या फिल्टरिंग आहे तिथे हलवतो. एकत्रीकरणापूर्वी प्रत्येक सबनेटसाठी सेवा नियम सूचीबद्ध करा, अन्यथा ती तुलना कधीच होत नाही.

प्रोटोकॉल आणि पोर्टची मूल्ये सेलेक्टरचा भाग आहेत, पर्यायी अतिरिक्त नाही. मूळ धोरणाने ती मर्यादित केली असतील, तर एकत्रीकरणाने तीच मर्यादा वाहून नेली पाहिजे, अन्यथा बदल म्हणजे राउटिंगचा वेश घातलेला परवानगी बदल आहे. मर्यादाच मूळ धोरणाचा हेतू असेल, तर सारांशानंतरही ती स्पष्ट ठेवा आणि नोंदीत तसे लिहा.

निकाल प्रत्येक प्रिफिक्सनुसार वाचणे

बदलानंतर कॉन्फिगर केलेले नाही तर स्थापित केलेले पहा. मग प्रत्येक प्रिफिक्समधून प्रत्येक दिशेने प्रवाह निर्माण करा, आणि तो हाताळणाऱ्या असोसिएशनचे काउंटर तपासा. एका असोसिएशनवर रहदारी निर्माण करणारे दोन प्रिफिक्स ठीक आहेत; दोन प्रिफिक्सांपैकी एक काहीच निर्माण करत नाही हाच शोध आहे.

हे वापरकर्ते वापरतात त्या त्याच अनुप्रयोगाने करा. गेटवेवरून उगम पावणारी चाचणी त्याच्या मागील क्लायंटपेक्षा वेगळा मार्ग तपासते, आणि सेलेक्टरचे दोष नेमके त्या फरकात लपतात. व्यस्त असाव्या अशा प्रिफिक्सवरील सपाट काउंटर कोणत्याही लॉग ओळीपेक्षा मजबूत पुरावा आहे, कारण तो अनुपस्थिती मोजतो.

बदल परत करण्यायोग्य करणे

नवे धोरण प्रत्येक प्रिफिक्स संयोजनातून तपासले जाईपर्यंत जुने धोरण कॉन्फिगरेशनमध्ये ठेवा, आणि प्रत्येक प्रवाह कोणत्या असोसिएशनमध्ये गेला ते नोंदवा. ऑफर बदलल्यावर बाजू असोसिएशन बदलत असेल, तर परताव्याने फक्त जुने पत्ते नाही तर जुनी ऑफर पुनर्संचयित केली पाहिजे.

खिडकी उघडण्यापूर्वी दुसऱ्या टोकाच्या मालकाशी समन्वय साधा. एका बाजूला स्पष्ट वाटणारे एकत्रीकरण दुसऱ्या बाजूला अस्वीकारार्ह गटीकरण असू शकते, आणि बदलाच्या वेळी ते कळणे महाग पडते. ऑफर केलेल्या गटीकरणावर लिखित सहमती द्या, मग देवघेव जे स्थापित करते त्याशी त्याची तुलना करा. ती सहमती पुढच्या आठवड्यात नाहीशी होणाऱ्या चॅट थ्रेडमध्ये नाही, बदल तिकिटात ठेवा.