साइटों के टकराने से पहले निजी VPN पता श्रेणियों की योजना बनाएँ

दो साइटें जो दोनों 192.168.1.0/24 का उपयोग करती हैं, दोनों इंटरनेट तक पहुँच सकती हैं और फिर भी एक-दूसरे तक नहीं पहुँच पातीं। गेटवे कोई त्रुटि नहीं देता; वह उस उपसर्ग के लिए एक ही रूट स्थापित करता है और हर पैकेट उस साथी को भेजता है जिसने उसे पहले दावा किया। हैंडशेक, सिफ़र सूची या इंटरफ़ेस मीट्रिक में कुछ भी नहीं बताता कि कौन सा साथी गलत है। पता योजना डिज़ाइन का वह हिस्सा है जो किसी के जुड़ने से पहले इसे तय करता है।

हर उस स्थान की सूची बनाएँ जहाँ पहुँचना ज़रूरी है

जिन श्रेणियों को रूट करना है उन्हें लिखें, केवल वे नहीं जिन्हें आप कॉन्फ़िगर कर रहे हैं। इसका अर्थ है साइट LAN, VPN क्लाइंट पूल, क्लाउड सबनेट, प्रबंधन और आउट-ऑफ़-बैंड नेटवर्क, प्रयोगशाला खंड और वे नेटवर्क जिनसे उपयोगकर्ता घर से आमतौर पर जुड़ते हैं। 192.168.1.0/24 के रूप में भेजा जाने वाला उपभोक्ता राउटर काल्पनिक नहीं है, और वही उपसर्ग होटलों और सम्मेलन स्थलों में दिखता है। सूची उपसर्ग, स्वामी और उद्देश्य की तालिका है, और यही एकमात्र दस्तावेज़ है जो एक ही श्रेणी दो बार देने से रोकता है।

अगले साल में जिन उपसर्गों की अपेक्षा है उन्हें जोड़ें, क्योंकि केवल आज को ढकने वाली योजना पहली नई साइट पर विफल होती है। हर पंक्ति में अंकित करें कि इसे कौन बदल सकता है, केवल यह नहीं कि इसका स्वामी कौन है।

पुनःउपयोग ही इसे कठिन बनाता है: निजी स्थान सीमित है और हर संगठन 10.0.0.0/8 को अपना मानता है। कोई योजना वादा नहीं कर सकती कि भविष्य का कोई अतिथि LAN आपके किसी उपसर्ग पर नहीं गिरेगा, इसलिए डिज़ाइन को कहना होगा कि जब ऐसा होता है तब क्या होता है। दो नियम अधिकांश काम करते हैं। क्लाइंट पूल को एक सतत ब्लॉक में रखें जिसका आप सारांश बना सकें, और ऐसी श्रेणी कभी न दें जिसे कोई दूसरी टीम पहले से रूट करती हो। बाकी सब एक रिकॉर्ड है जिसे कोई अद्यतन रखता है।

क्यों एक ओवरलैप रूटिंग तालिका को हरा देता है

रूट एक उपसर्ग और अगली छलांग है, और अग्रेषण सबसे लंबा मेल खाता उपसर्ग चुनता है। जब दो साथी दोनों एक ही 192.168.1.0/24 का दावा करते हैं, तालिका उसके लिए एक ही प्रविष्टि रखती है, इसलिए दोनों साइटों का ट्रैफ़िक एक ही टनल से निकलता है। दूसरी साइट गलत कॉन्फ़िगर नहीं है; वह अगम्य है क्योंकि पहली उन्हीं पतों के लिए उत्तर देती है। कोई मीट्रिक उन्हें अलग नहीं कर सकता, क्योंकि मेल मीट्रिक देखे जाने से पहले होता है।

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

क्लाइंट पूल और साइट श्रेणियों को जानबूझकर नापें

VPN क्लाइंट पूल वह श्रेणी है जिससे गेटवे एक बार में एक पता देता है, इसलिए उसका आकार समवर्तीता सीमित करता है। /24 में 254 उपयोगी पते होते हैं, जो छोटी टीम के लिए उदार और कंटेनर चलाने वाली शाखा के लिए तंग है; /22 निजी स्थान में अतिरिक्त कुछ खर्च नहीं करता और बहस हटा देता है। पूल को सतत रखें और हर साइट LAN से दूर रखें, ताकि क्लाइंट की ओर सारांश रूट कभी किसी साइट को न निगल जाए। पूल खाली होने पर भी श्रेणी आरक्षित रखें, क्योंकि बिना लिखी श्रेणी ही वह है जिसे अगला इंजीनियर आवंटित करेगा।

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

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

अनुवाद और पुनःक्रमांकन अलग-अलग समस्याएँ हल करते हैं

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

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

तैनाती से पहले दूर की ओर से परखें

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

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

रिकॉर्ड ही परिणाम है। तीन लोगों की स्मृति में रहने वाली योजना उस पहले अवसर पर विफल होती है जब उनमें से कोई छुट्टी पर हो, और उत्पादन में मिला ओवरलैप तालिका से अधिक महंगा पड़ता है।