दो /24 की जगह एक /23: बातचीत में क्या बदलता है

दो सटे हुए /24 साफ़-सुथरे ढंग से एक /23 में समा जाते हैं, और यह सुव्यवस्थित गणित लोगों को यह विश्वास दिला देता है कि बदलाव केवल दिखावटी है। यह पतों का गणित है, और टनल को चयनकर्ताओं की परवाह है, जो बातचीत का प्रस्ताव हैं, किसी नेटवर्क का वर्णन नहीं। छोटी पंक्ति उसी ट्रैफ़िक को सुरक्षित छोड़ सकती है, इरादे से ज़्यादा सुरक्षित कर सकती है, या उसका आधा हिस्सा ढक नहीं पा सकती — यह इस पर निर्भर है कि दोनों पक्ष क्या स्वीकार करने को तैयार हैं। स्थापित परिणाम पढ़ना ही यह जानने का एकमात्र तरीका है कि तीनों में से कौन-सा हुआ।

तीन तथ्य जिन्हें लोग एक में मिला देते हैं

पता-समुच्चय बताता है कि किन होस्टों को सुरक्षित रखा जाना है। समूहन बताता है कि वे पते कैसे प्रस्तुत किए जाते हैं: एक चयनकर्ता या कई, एक संबंध में या अधिक में। तय किया गया परिणाम बताता है कि दोनों पक्षों ने वास्तव में क्या स्थापित किया, और यह पहले दो में से किसी से भी सँकरा हो सकता है।

इन्हें बदलाव के रिकॉर्ड में अलग-अलग लिखें। कॉन्फ़िगरेशन की एक पंक्ति अक्सर तीन अलग जवाब छिपाती है। जो समीक्षक इन्हें अलग नहीं कर सकता, वह बदलाव को मंज़ूरी भी नहीं दे सकता।

उत्तरदाता आपके एकत्रीकरण के साथ क्या कर सकता है

IKEv2 उत्तरदाता प्रस्तुत चयनकर्ता-युग्म को उस उपसमुच्चय तक सँकरा कर सकता है जिसे वह स्वीकार करने को तैयार है, और यदि कुछ भी स्वीकार्य न हो तो प्रस्ताव को सीधे अस्वीकार कर सकता है। वह यह भी बता सकता है कि अतिरिक्त ट्रैफ़िक को इस संबंध में समाने के बजाय दूसरा संबंध चाहिए।

जो उत्तरदाता कुछ भी स्वीकार नहीं करता, वह इसके बजाय त्रुटि लौटाता है, जो कम-से-कम यह बताती है कि प्रस्ताव अस्वीकार हुआ, चुपचाप सँकरा नहीं किया गया।

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

जहाँ सारांश चुपचाप एक सीमा मिटा देता है

दो /24 अलग-अलग सेवा-नियम रख सकते हैं: एक केवल प्रबंधन प्रोटोकॉल की अनुमति दे सकता है, दूसरा सामान्य अनुप्रयोग की। IP स्तर पर दोनों पतों को ढकने वाला चयनकर्ता उन नियमों को नहीं बचाता, और सारांश सीमा को टनल के पीछे जो भी फ़िल्टरिंग है उसमें स्थानांतरित कर देता है। एकत्र करने से पहले हर सबनेट के सेवा-नियम सूचीबद्ध करें, वरना वह तुलना कभी नहीं होती।

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

हर प्रीफ़िक्स के हिसाब से परिणाम पढ़ना

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

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

बदलाव को उलटने योग्य बनाना

मूल नीति को कॉन्फ़िगरेशन में रखें जब तक नई नीति हर प्रीफ़िक्स संयोजन से परखी न जाए, और नोट करें कि हर प्रवाह किस संबंध में उतरा। यदि प्रस्ताव बदलने पर पक्ष संबंध बदल देता है, तो रोलबैक को पुराना प्रस्ताव बहाल करना होगा, केवल पुराने पते नहीं।

विंडो खुलने से पहले दूसरे सिरे के मालिक के साथ समन्वय करें। जिस सारांश को एक पक्ष स्पष्ट मानता है, वह दूसरे के लिए अस्वीकार्य समूहन हो सकता है, और बदलाव के दौरान यह पता लगाना महँगा है। प्रस्तुत समूहन पर लिखित रूप में सहमत हों, फिर उसकी तुलना उससे करें जो विनिमय स्थापित करता है। उस सहमति को बदलाव टिकट में रखें, ऐसे चैट थ्रेड में नहीं जो अगले हफ़्ते गायब हो जाए।