साइट-देखि-साइट VPN मा स्ट्याटिक रुट वा राउटिङ प्रोटोकल?
प्रिफिक्सको परिवर्तन, फेलओभर व्यवहार र सञ्चालन क्षमताले यो टुंगो लगाउँछ। प्रत्येक विकल्प सही राख्ने लागत तोल्नुहोस्, त्यसपछि असफलताको मार्ग परीक्षण गर्नुहोस्।
दुवै विकल्पले साइटहरूबीच प्याकेट बोक्छन्, त्यसैले निर्णय कुन प्रोटोकल नयाँ हो भन्नेमा होइन, र टनेलको आकारले पनि यसलाई टुंगो लगाउँदैन। तीन सर्तले यसलाई टुंगो लगाउँछन्: कति प्रिफिक्स परिवर्तन हुन्छन् र कति पटक, डिजाइनलाई मार्गहरूबीच स्वचालित फेलओभर चाहिन्छ कि, र टोलीले राति तीन बजे कति नियन्त्रण-तह मेसिनरी चलाउन सक्छ। यिनको इमानदारीपूर्वक जवाफ दिनुहोस्, छनोट सामान्यतया आफै हुन्छ। यो लेखको बाँकी भाग प्रत्येक जवाफको मूल्य हो।
तीन सर्तले टुंगो लगाउँछन्
पहिलो सर्त परिवर्तन हो। स्पष्ट स्वामित्व भएका केही स्थिर सबनेट वर्षौंसम्म हातले मर्मत गर्न सकिन्छ, र प्रत्येक रुट कसैले पढेर जाँच्न सक्ने एउटा लाइन रहन्छ। परियोजनाहरू आउने-जाने क्रममा सर्ने दर्जनौं प्रिफिक्स फरक समस्या हुन्, किनभने प्रत्येक सर्ने क्रम पुरानो मार्ग सम्झिरहेको प्रत्येक यन्त्रसम्म पुग्नुपर्छ।
दोस्रो सर्त असफलताको व्यवहार हो। जब ब्याकअप मार्ग मानिसलाई थाहै नदिई सक्रिय हुनुपर्छ, केही कुराले असफलता पहिचान गरी रुट फिर्ता लिनुपर्छ। स्ट्याटिक राउटिङले त्यो ट्र्याकिङ वा सशर्त स्थापना मार्फत मात्र गर्न सक्छ, र तपाईंले पहिले नै सोचेका असफलताहरूका लागि मात्र।
तेस्रो सर्त दोस्रो नियन्त्रण तहको चाहना हो। राउटिङ प्रोटोकलले सत्र, प्रमाणीकरण, फिल्टर र छनोट नीति थप्छ, र यीमध्ये प्रत्येकलाई निगरानी र परिवर्तन प्रक्रिया चाहिन्छ। यो स्थायी सञ्चालन लागत हो, एक पटकको कन्फिगरेसन काम होइन।
| Condition | Points to static | Points to dynamic |
|---|---|---|
| Prefix churn | Rare, few, stable | Frequent, many, moving |
| Failover | Manual or tracked | Automatic withdrawal |
| Operations | No routing staff | Protocol monitoring exists |
तेस्रो अनुच्छेदमुनिको तालिका छोटो संस्करण हो, र त्यसपछिका तीन खण्डले प्रत्येक पङ्क्ति किन आफ्नो ठाउँमा छ भन्ने व्याख्या गर्छन्। छनोट गर्नुअघि पङ्क्तिहरूलाई आफ्नै साइट सङ्ख्यासँग भिडाएर पढ्नुहोस्, किनभने सञ्चालन लागत बेवास्ता गर्ने निर्णय आधा निर्णय मात्र हो।
स्ट्याटिक राउटिङले वास्तवमा कति खर्च गर्छ
स्ट्याटिक रुट टनेलको दुवै छेउमा सही हुनुपर्छ। सबनेट थप्नु भनेको टाढाको गेटवे, स्थानीय गेटवे र सामान्यतया फर्कने मार्ग सम्पादन गर्नु हो, र यीमध्ये कुनै पनि बिर्सँदा अनुप्रयोगको बगजस्तो देखिने एकतर्फी असफलता उत्पन्न हुन्छ। अनुप्रयोग टोलीले समयसमाप्ति देख्छ, जबकि सञ्जाल टोलीले अवस्थित र देख्दा स्वस्थ देखिने रुट देख्छ। कुनै टोली गलत छैन, र त्यसैले यो असफलताको स्थान पत्ता लगाउन यति समय लाग्छ।
स्ट्याटिक प्रविष्टि त्यसको तलको मार्ग हराएपछि पनि स्थापित रहन्छ। प्लेटफर्मले ट्र्याकिङ दिएन भने, रुट अब अगाडि नपठाउने अर्को हपतिर सङ्केत गरिरहन्छ, र ट्राफिक फेलओभर नभई हराउँछ। त्यो मौनता नै सरल विकल्प छान्दा तपाईंले स्वीकार गर्ने खर्च हो।
प्रत्येक रुटको छेउमा ट्र्याकिङ विधि लेख्नुहोस्, यसले कुन असफलताहरू ढाक्छ भनी टिप्नुहोस्, र सूची टनेल कन्फिगरेसनसँगै राख्नुहोस्। अन्यथा अर्को अवरोध सञ्जालले होइन, प्रयोगकर्ताले पत्ता लगाउनेछ, र त्यो सधैं बढी महँगो पत्ता लगाउने काम हो।
डायनामिक राउटिङले वास्तवमा कति खर्च गर्छ
प्रोटोकलले नयाँ प्रिफिक्स घोषणा गर्छ, पुग्न नसकिने फिर्ता लिन्छ र मार्गहरूबीच प्राथमिकता व्यक्त गर्छ। धेरै साइट वा अतिरिक्त टनेललाई प्रत्येक परिवर्तनमा समन्वित सम्पादन चाहिने अवस्थामा यो साँच्चै उपयोगी हुन्छ। प्रोटोकलले सबैभन्दा नराम्रो क्षणमा तपाईंलाई चकित पार्न सक्ने कारण पनि यही हो। ती क्रियाहरूमध्ये प्रत्येक तपाईंले आफै नगरेको अवस्था परिवर्तन हो।
यसले असहमत हुन सक्ने दुई अवस्था सिर्जना गर्छ। टनेल माथि हुँदा राउटिङ सत्र तल हुन सक्छ, र सत्र माथि हुँदा यसका घोषणाहरूले अनुप्रयोगलाई चाहिने सबनेट छोड्न सक्छन्। दुवै आधा काम गर्ने सञ्जालजस्तो देखिन्छन्, र कुनै पनि टनेल स्थिति पृष्ठबाट देखिँदैन।
त्यसैले फिल्टर र नीति पछिको सोच होइन, डिजाइनको भाग बन्छन्। सबै कुरा घोषणा गर्ने प्रोटोकलले अन्ततः केही गलत घोषणा गर्नेछ, र गलत प्रिफिक्स त्यसलाई सुधार्न सक्ने व्यक्तिभन्दा छिटो यात्रा गर्छ। पहिलो सत्र सक्षम गर्नुअघि फिल्टर लेख्नुहोस्, ताकि पहिलो घोषणा पहिलेदेखि नै जानाजानी होस्।
राउटिङ सत्रले के भन्न सक्छ त्यो नियन्त्रण गर्नुहोस्
प्रत्येक पीयरका लागि अनुमत प्रिफिक्स सूची तय गर्नुहोस् र आगमनमा लागू गर्नुहोस्, किनभने बहिर्गामी फिल्टरले पीयरलाई तपाईंलाई पूर्वनिर्धारित रुट पठाउनबाट रोक्न सक्दैन। पूर्वनिर्धारित रुट र समग्र यहाँ महँगा गल्ती हुन्: तिनले वैध देखिने एउटा सिकेको प्रविष्टिले असम्बन्धित मार्गहरू चुपचाप बदल्न सक्छन्। डिजाइनले साँच्चै नचाहेसम्म तिनलाई स्पष्ट रूपमा अस्वीकार गर्नुहोस्।
पहिलो सत्र उठ्नुअघि प्रत्येक सञ्जालको छेउमा मालिक साइट लेख्नुहोस्, किनभने त्यो म्यापिङ फिल्टर सूचीको स्रोत हो, कागजातको शृंगार होइन। त्यो बिना फिल्टर सम्पादन गर्ने व्यक्तिले कुन साइटले प्रिफिक्स घोषणा गर्नुपर्छ भनी अनुमान गर्नुपर्छ।
दुई प्रोटोकलबीचको पुनर्वितरण लूप सुरु हुने ठाउँ हो, र जहाँ एउटै प्रिफिक्स सफा तुलना नहुने विशेषतासहित दुई पटक आउँछ। विशेष आवश्यकताले बाध्य नपारेसम्म पुनर्वितरणलाई डिजाइनबाहिर राख्नुहोस्, र हुनैपर्ने भए सीमानामा मार्गहरू चिन्ह लगाई फिल्टर गर्नुहोस्।
रुट-आधारित टनेल इन्टरफेसले डायनामिक राउटिङलाई प्रस्तुत गर्न सजिलो बनाउँछ, किनभने टनेल छनोटकर्तासँग मिल्ने नीतिको सट्टा मार्गहरू भएको इन्टरफेस बन्छ। यसले पीयर दायराको प्रश्न हटाउँदैन: IPsec छनोटकर्ताले अझै पनि तपाईंले रुट गर्न चाहेको ट्राफिकलाई अनुमति दिनुपर्छ।
असफलताको मार्ग परीक्षण गर्नुहोस्, खुसीको मार्ग होइन
तपाईंले जे छाने पनि, एउटा अपलिङ्क तल झार्नुहोस् र ट्राफिक सर्छ वा तपाईंले कागजात गरेअनुसार असफल हुन्छ भनी पुष्टि गर्नुहोस्। दुवै मार्ग स्वस्थ हुँदा मात्र परीक्षण गरिएको डिजाइन भनेको बिल्कुलै नपरीक्षण गरिएको डिजाइन हो। त्यहीँ हुँदा पहिचान समय नाप्नुहोस्, किनभने तपाईंले नापेको सङ्ख्या नै प्रयोगकर्ताले भोग्ने सङ्ख्या हो।
त्यसपछि फर्कने मार्ग स्वतन्त्र रूपमा पुष्टि गर्नुहोस्, किनभने VPN माथिको असममित राउटिङ सामान्य छ र अवस्था-सङ्ग्राहक यन्त्रले जवाफ नफ्याँकेसम्म अदृश्य रहन्छ। एक दिशामा चल्ने प्रवाहले मार्गको आधा मात्र प्रमाणित गर्छ।
कामको क्रम: प्रिफिक्स गन्नुहोस्, असफलता कसरी पहिचान गर्ने भनी तय गर्नुहोस्, प्रोटोकल कसले चलाउन सक्छ जाँच्नुहोस्, के घोषणा हुन्छ नियन्त्रण गर्नुहोस्, र त्यसपछि एउटा अवरोध सुरुदेखि अन्त्यसम्म परीक्षण गर्नुहोस्। प्रत्येक चरणले अर्को चरणलाई चाहिने तथ्य दिन्छ।