साइट-टू-साइट VPN वर स्टॅटिक रूट्स की राउटिंग प्रोटोकॉल?

दोन्ही पर्याय साइट्समध्ये पॅकेट्स नेतात, त्यामुळे निर्णय कोणता प्रोटोकॉल नवीन आहे यावर नाही, आणि टनेलचा आकारही तो ठरवत नाही. तीन अटी तो ठरवतात: किती प्रीफिक्स बदलतात आणि किती वेळा, डिझाइनला मार्गांमध्ये स्वयंचलित फेलओव्हर हवा का, आणि संघ रात्री तीन वाजता किती नियंत्रण-स्तर यंत्रणा चालवू शकतो. यांना प्रामाणिक उत्तर द्या आणि निवड सहसा स्वतः होते. या लेखाचा उर्वरित भाग प्रत्येक उत्तराची किंमत आहे.

तीन अटी ठरवतात

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

दुसरी अट अपयशाचे वर्तन आहे. बॅकअप मार्ग माणसाच्या लक्षात न येता सक्रिय व्हायचा असेल, तर काहीतरी अपयश ओळखून रूट मागे घ्यायला हवे. स्टॅटिक राउटिंग हे केवळ ट्रॅकिंग किंवा सशर्त इन्स्टॉलेशनने करू शकते, आणि केवळ आपण आधीच विचार केलेल्या अपयशांसाठी.

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

तिसऱ्या परिच्छेदाखालील तक्ता ही संक्षिप्त आवृत्ती आहे, आणि त्यानंतरचे तीन विभाग प्रत्येक ओळ का तिच्या जागी आहे ते स्पष्ट करतात. निवडण्यापूर्वी ओळी आपल्या स्वतःच्या साइट संख्येशी पटवून वाचा, कारण कार्यचालन खर्च दुर्लक्षणारा निर्णय अर्धाच निर्णय असतो.

स्टॅटिक राउटिंग प्रत्यक्षात किती खर्च करते

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

स्टॅटिक नोंद खालील मार्ग नाहीसा झाल्यावरही स्थापित राहते. प्लॅटफॉर्म ट्रॅकिंग देत नसेल, तर रूट आता पुढे न पाठवणाऱ्या पुढील हॉपकडे दाखवत राहतो, आणि रहदारी फेलओव्हर होण्याऐवजी गायब होते. तोच शांतपणा सोपा पर्याय निवडताना आपण स्वीकारत असलेला खर्च आहे.

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

डायनॅमिक राउटिंग प्रत्यक्षात किती खर्च करते

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

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

म्हणून फिल्टर आणि धोरण ही नंतरची विचारसरणी नसून डिझाइनचा भाग बनते. सर्व काही जाहीर करणारा प्रोटोकॉल शेवटी काहीतरी चुकीचे जाहीर करेल, आणि चुकीचा प्रीफिक्स तो दुरुस्त करू शकणाऱ्या व्यक्तीपेक्षा वेगाने प्रवास करतो. पहिले सत्र सक्षम करण्यापूर्वी फिल्टर लिहा, जेणेकरून पहिली जाहिरात आधीच जाणीवपूर्वक असेल.

राउटिंग सत्र काय बोलू शकते ते नियंत्रित करा

प्रत्येक पीअरसाठी परवानगी असलेली प्रीफिक्स यादी ठरवा आणि ती आवकेवर लागू करा, कारण बहिर्गामी फिल्टर पीअरला आपल्याला डीफॉल्ट रूट पाठवण्यापासून थांबवू शकत नाही. डीफॉल्ट रूट्स आणि एकत्रीकरणे हे येथे महाग चुका आहेत: ते कायदेशीर दिसणाऱ्या एका शिकलेल्या नोंदीने असंबंधित मार्ग गुपचूप बदलू शकतात. डिझाइन खरोखर इच्छित नसेल तर ते स्पष्टपणे नाकारा.

पहिले सत्र उभे राहण्यापूर्वी प्रत्येक नेटवर्कजवळ मालक साइट लिहा, कारण ते मॅपिंग फिल्टर यादीचा स्रोत आहे, दस्तऐवजीकरणाची नटाई नाही. त्याशिवाय फिल्टर संपादणाऱ्याला कोणत्या साइटने प्रीफिक्स जाहीर केला पाहिजे याचा अंदाज घ्यावा लागतो.

दोन प्रोटोकॉलमधील पुनर्वितरण म्हणजे लूप सुरू होण्याची जागा, आणि जिथे तोच प्रीफिक्स स्वच्छ तुलना होऊ न शकणाऱ्या गुणधर्मांसह दोनदा येतो. विशिष्ट गरज भाग पाडेपर्यंत पुनर्वितरण डिझाइनबाहेर ठेवा, आणि असणेच आवश्यक असल्यास सीमेवर मार्ग चिन्हांकित करून फिल्टर करा.

रूट-आधारित टनेल इंटरफेस डायनॅमिक राउटिंगचे प्रतिनिधित्व सोपे करतात, कारण टनेल निवडकांशी जुळणाऱ्या धोरणाऐवजी मार्ग असलेला इंटरफेस बनते. यामुळे पीअर व्याप्तीचा प्रश्न जात नाही: IPsec निवडकांना अजूनही आपण राउट करू इच्छित असलेल्या रहदारीला परवानगी द्यावी लागते.

अपयशाचा मार्ग तपासा, आनंदाचा मार्ग नाही

आपण काहीही निवडा, एक अपलिंक खाली घ्या आणि रहदारी सरकते किंवा आपण दस्तऐवजीकृत केल्याप्रमाणे अपयशी ठरते याची खात्री करा. केवळ दोन्ही मार्ग निरोगी असताना तपासलेले डिझाइन म्हणजे अजिबात न तपासलेले डिझाइन. तिथे असतानाच शोध वेळ मोजा, कारण आपण मोजलेली संख्या हीच वापरकर्ते अनुभवतील.

मग परतीचा मार्ग स्वतंत्रपणे तपासा, कारण VPN वरचे असममित राउटिंग सामान्य आहे आणि स्थिती-संग्राहक उपकरण उत्तरे टाकून देईपर्यंत अदृश्य असते. एका दिशेने चालणारा प्रवाह मार्गाचा फक्त अर्धा भाग सिद्ध करतो.

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