साइट-से-साइट VPN पर स्टैटिक रूट या राउटिंग प्रोटोकॉल?

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

तीन शर्तें इसे तय करती हैं

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

दूसरी शर्त विफलता का व्यवहार है। जब बैकअप रास्ते को बिना किसी इंसान के ध्यान दिए सक्रिय होना हो, तो किसी को विफलता पहचाननी होगी और रूट वापस खींचना होगा। स्टैटिक राउटिंग यह केवल ट्रैकिंग या सशर्त इंस्टॉलेशन से कर सकती है, और केवल उन विफलताओं के लिए जिन्हें आपने पहले से सोचा हो।

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

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

स्टैटिक राउटिंग वास्तव में क्या कीमत लेती है

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

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

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

डायनामिक राउटिंग वास्तव में क्या कीमत लेती है

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

यह दो स्थितियाँ बनाता है जो असहमत हो सकती हैं। टनल ऊपर हो सकती है जबकि राउटिंग सत्र नीचे हो, और सत्र ऊपर हो सकता है जबकि उसकी घोषणाएँ वह सबनेट छोड़ दें जिसकी एप्लिकेशन को ज़रूरत है। दोनों आधा काम करते नेटवर्क जैसे लगते हैं, और कोई भी टनल स्थिति पृष्ठ से दिखाई नहीं देता।

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

नियंत्रित करें कि राउटिंग सत्र क्या कह सकता है

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

पहला सत्र उठने से पहले हर नेटवर्क के पास स्वामी साइट लिखें, क्योंकि वही मैपिंग फ़िल्टर सूची का स्रोत है, दस्तावेज़ीकरण का शृंगार नहीं। इसके बिना फ़िल्टर संपादित करने वाले को अनुमान लगाना पड़ता है कि कौन-सी साइट प्रीफ़िक्स की घोषणा करनी चाहिए।

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

रूट-आधारित टनल इंटरफ़ेस डायनामिक राउटिंग को दर्शाना आसान बनाते हैं, क्योंकि टनल सिलेक्टर से मेल खाने वाली नीति के बजाय रूटों वाला इंटरफ़ेस बन जाती है। यह पीयर दायरे का सवाल नहीं हटाता: IPsec सिलेक्टरों को अब भी वही ट्रैफ़िक अनुमत करना होगा जिसे आप रूट करना चाहते हैं।

विफलता का रास्ता जाँचें, सुखद रास्ता नहीं

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

फिर वापसी रास्ते की स्वतंत्र रूप से पुष्टि करें, क्योंकि VPN पर असममित राउटिंग सामान्य है और अदृश्य रहती है जब तक कोई स्थिति-संग्राहक डिवाइस उत्तर न गिरा दे। एक दिशा में चलने वाला प्रवाह रास्ते का केवल आधा हिस्सा सिद्ध करता है।

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