फ़्लोटिंग VPN बैकअप रूट नहीं संभालता: फ़ेलओवर चेकलिस्ट

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

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

उस विफलता का नाम रखें जिसे बैकअप को ढकना है

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

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

दूरी से कुछ पहचानने की माँग करना बंद करें

अधिक दूरी रूट को कम पसंदीदा बनाती है। पूरा काम यही है। जब तक प्राथमिक स्टैटिक रूट पात्र रहता है, फ़्लोटिंग रूट निष्क्रिय रहता है, और यह बग नहीं बल्कि सही व्यवहार है। विफलता तभी दिखती है जब प्राथमिक वापस लिया जाए या अगम्य चिह्नित हो।

स्टैटिक रूट के लिए इसके लिए स्पष्ट ट्रैकर चाहिए:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

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

पता लगाएँ कि प्रोब के अपने पैकेट कहाँ जाते हैं

स्वास्थ्य प्रोब का भी एक रूट होता है। डेटा ट्रैफ़िक VPN पर जाने के बाद, उसी दूर के पते पर बिना रोक का प्रोब उसका पीछा कर सकता है, सफल हो सकता है, और प्राथमिक के लौटने का प्रमाण पढ़ा जा सकता है। ट्रैफ़िक टूटे पथ पर लौटता है और चक्र दोहराता है।

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

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

लक्ष्य जोड़ने से पहले तय करें कि प्रोब परिणाम का अर्थ क्या है

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

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

वापसी पथ और सत्रों की कहानी जाँचें

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

प्रबंधन पहुँच को परीक्षण वाले पथ से दूर रखें। अगर आपका एकमात्र प्रवेश प्राथमिक से है, तो फ़ेलओवर परीक्षण आपको गलत व्यवहार करने वाले उपकरण से बाहर बंद कर देता है।

स्वीकृति क्रम चलाएँ

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

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