साइट्स एकमेकांशी टकराण्यापूर्वी खाजगी 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 बहुतेक राउटिंग चुका लपवते। सामान्य घरगुती राउटरमागे क्लायंट जोडा, नंतर प्रत्येक साइटवरील सेवा आणि क्लायंट पूलमधील एका सेवेपर्यंत पोहोचा। उलटी दिशाही तपासा, साइट होस्टकडून क्लायंटकडे, कारण परतीचे मार्ग स्वतंत्रपणे अपयशी ठरतात। फक्त गेटवेला पिंग करणारी चाचणी टनेल सुरू आहे हे सिद्ध करते आणि त्यापेक्षा जास्त काही नाही।

श्रेणी, मालक आणि अनुवाद मॅपिंग एका सामायिक नोंदीत ठेवा जी पुढील साइट काहीही वाटण्यापूर्वी वाचते। साइट जोडली की तिचा आढावा घ्या, आणि नोंद नसलेल्या श्रेणीला आश्चर्य नाही तर दोष माना।

नोंद हाच निकाल आहे। तीन लोकांच्या स्मरणात राहणारी योजना त्यांच्यापैकी एक जेव्हा सुट्टीवर असतो तेव्हाच अपयशी ठरते, आणि उत्पादनात आढळलेला ओव्हरलॅप तक्त्यापेक्षा जास्त महाग पडतो।