IPv6 VPN की पता योजना को एक साल बाद भी पढ़ने योग्य कैसे रखें
पढ़ने योग्य योजना बताती है कि कौन-सा प्रीफ़िक्स किस साइट का है और जवाब कैसे लौटते हैं। हर प्रविष्टि के पास भूमिकाएँ, संकेतन, प्रत्यायोजन और वापसी मार्ग लिखें।
दो सवाल तय करते हैं कि पता योजना अपनी जगह कमाती है या नहीं: कौन-सा प्रीफ़िक्स किस साइट का है, और जवाब उस साइट से बाहर कैसे आता है। दोनों का एक ही बार में जवाब दें और रखरखाव करने वाला बिना किसी से पूछे पीयर बदल सकता है। दस्तावेज़ में बाकी सब कुछ उन्हीं दो जवाबों को सहारा देने के लिए है। जो किसी भी जवाब को सहारा नहीं देता, वह सजावट है।
पीयर छूने से पहले पाठक को क्या जवाब देना होता है
संपीड़न पतों को साफ़-सुथरा दिखाता है, और सफ़ाई संरचना नहीं है। संरचना यह जानना है कि प्रदाता ने कौन-सी श्रेणी सौंपी, आपने कौन-सी चुनी, कौन-सा क्लाइंट पूल है और कौन-सा किसी साइट के पीछे है।
उस सहकर्मी के लिए लिखें जो अगली तिमाही में जुड़ेगा और दूसरी साइट जोड़ेगा। पन्ने पर कुछ भी उसे नहीं बताता कि प्रीफ़िक्स कहाँ से आया, जब तक प्रविष्टि न बताए। इसे छोड़ दें और पहला बदलाव पुरातत्व बन जाता है।
योजना की हर पंक्ति को क्या ढोना होता है
चार फ़ील्ड प्रविष्टि को समीक्षा-योग्य बनाते हैं: प्रीफ़िक्स कितना लंबा है, उसका मालिक कौन है, ट्रैफ़िक आगे कहाँ जाता है और कौन-सा घटक मान बाँटता है। इन्हें चल रहे कॉन्फ़िगरेशन के सामने रखें और हर असहमति अपने आप सामने आ जाती है। पिछले महीने हटाए गए टनल की ओर इशारा करने वाला अगला हॉप तुरंत गलत दिखता है, घुल-मिल जाने के बजाय।
भूमिकाओं को अलग पंक्तियों में रखें, भले ही उनमें से दो आज एक ही प्रीफ़िक्स साझा करें। उन्हें मिलाने से बाद का विभाजन नए आवंटन जैसा पढ़ा जाता है, सुधार जैसा नहीं।
| Entry | Fields to record | Why a reviewer needs it |
|---|---|---|
| Endpoint addresses | Prefix, owning side, session initiator | Firewall rules and peer config both read it |
| Tunnel interfaces | Prefix and length, next hop, interface name | Shows the path a packet actually takes |
| Client allocations | Pool range, size, distributing component | Shows room left before a redesign |
| Downstream networks | Prefix, site label, return route | Explains a reply that never arrives |
कहाँ विहित पाठ और कॉन्फ़िगरेशन वाक्य-रचना अलग होते हैं
RFC 5952 पते के लिए एक ही पाठ रूप तय करता है: छोटे अक्षर, शुरुआती शून्य नहीं, और शून्य समूहों की सबसे लंबी श्रृंखला ठीक एक बार संपीड़ित। इसे नोट्स, टिकटों और बदलाव रिकॉर्ड में इस्तेमाल करें ताकि दो दस्तावेज़ बिना रूपांतरण के तुलना कर सकें। एक ही पते की दो वर्तनियाँ देखने वाले पाठक ऐसे अंतर की खोज में लग जाते हैं जो है ही नहीं। यहाँ एकरूपता सस्ती है और यह झूठे अलार्म की पूरी श्रेणी हटा देती है।
कॉन्फ़िगरेशन फ़ाइलें अपने नियम मानती हैं, और वे पठनीयता के नियम नहीं हैं। पोर्ट के साथ जोड़े गए पते को कोष्ठक चाहिए, भले ही नंगे पते को न चाहिए, और नोट से कॉन्फ़िगरेशन फ़ाइल में कॉपी करने पर यह भेद बिना चेतावनी खो जाता है। हर फ़ील्ड कौन-सा रूप इस्तेमाल करता है, यह नाम दें, वरना योजना वही प्रतिलिपि त्रुटि कराती है जिसे रोकना था।
दो संकेतन ठीक हैं जब तक हर एक पर लेबल हो। बिना लेबल का मिश्रण ही गलती को न्योता देता है।
कहाँ अतिव्यापी श्रेणियाँ और गुम वापसी मार्ग दिखते हैं
अतिव्यापन दूसरी गलतियों से ज़्यादा टिकता है क्योंकि जब तक दो साइटें एक ही श्रेणी के लिए जवाब न दें, कुछ गलत नहीं दिखता। साइट को लेबल करें और दस्तावेज़ी प्रक्रिया से स्थानीय-अद्वितीय प्रीफ़िक्स बनाएँ, न कि उदाहरण की नकल करें।
क्लाइंट सूची कभी नहीं बताती कि जवाब किस दिशा में जाता है। टनल जो पीयर श्रेणी ढोती है, उसके पास LAN गेटवे का वापसी मार्ग लिखें, और रिकॉर्ड उस दूरस्थ सबनेट को समझाता है जो अनुरोध पाता है और चुप रहता है। नीचे दी जाँचें मशीन पर चलाएँ और प्रविष्टि से तुलना करें। ip -6 route से मेल न खाने वाली योजना वह योजना है जिसे लोग पढ़ना छोड़ देते हैं।
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0पहुँच अनुमति नहीं है, और प्रीफ़िक्स कभी नीति का अर्थ नहीं देता। इच्छित पहुँच उस मार्ग के पास लिखें जिस पर वह लागू होती है। वरना अगला पाठक योजना के पते को उसके पीछे की हर सेवा तक पहुँचने की अनुमति मान लेता है।
योजना तीसरी साइट तक कैसे टिकती है
हर प्रीफ़िक्स को प्रत्यायोजित, स्थानीय रूप से आवंटित या किसी और तरीके से मार्गित चिह्नित करें। जो भी हिल सकता है, उसके लिए वह प्रक्रिया नाम दें जो उसे हिलाती है। फिर उन DNS रिकॉर्ड और फ़ायरवॉल नियमों की सूची बनाएँ जो उसी खिड़की में बदलने चाहिए, क्योंकि राउटर पर रुकने वाला प्रीफ़िक्स अपडेट आधा अधूरा है।
बदलाव के बाद, दस्तावेज़ संपादित करने से पहले बदलाव द्वारा छुई हर सीमा के पीछे के संसाधन तक पहुँचें। पिछले महीने का नेटवर्क बताने वाली योजना किसी से भी बुरी है, क्योंकि लोग उस पर भरोसा करते हैं। वापस लिए गए आवंटन उस तारीख के साथ सूचीबद्ध रखें जिस दिन वे गए, ताकि कोई गलती से उन्हें फिर न जारी करे। रहस्य फ़ाइल से बाहर रहते हैं; योजना नेटवर्क समझाती है, उसे खोलती नहीं।
योजना वहाँ रखें जहाँ बदलावों की समीक्षा होती है, उस कॉन्फ़िगरेशन के पास जिसका वह वर्णन करती है। जिस दस्तावेज़ को कोई दोबारा नहीं पढ़ता, वह उस नेटवर्क से तेज़ सड़ता है जिसका वह नक्शा बनाता है।