वायरलेस लिंक बॅकअप: राउटेड फेलओव्हर की एक सेगमेंट?

दोन इमारती, एक पॉइंट-टू-पॉइंट रेडिओ आणि दुसरा मार्ग होऊ शकणारा इंटरनेट VPN। बॅकअप स्वयंचलित होण्यापूर्वी एक प्रश्न बाकी जवळपास सर्व ठरवतो: काय टिकले पाहिजे — वेगवेगळ्या सबनेटमधील IP पोहोच की एक सामायिक इथरनेट सेगमेंट? रेडिओ केबलसारखा वागतो हे प्रत्येक ब्रॉडकास्ट फ्रेम इंटरनेटवर पाठवण्याचे कारण नाही। आधी या प्रश्नाचे उत्तर द्या, कारण दोन्ही उत्तरांना वेगळे लूप नियंत्रण, वेगळ्या आरोग्य तपासण्या आणि पुनर्प्राप्तीचा अर्थ याबद्दल वेगळी समज आवश्यक आहे।

बिघाडात काय टिकले पाहिजे ते ठरवा

काम सुरू ठेवणारी अनुप्रयोगांची यादी करा आणि ते Layer 3 पोहोच की Layer 2 समीपतेवर अवलंबून आहेत हे नोंदवा। फाइल शेअरिंग, डेटाबेस कनेक्शन आणि वेब सेवा सहसा फक्त मार्गांची काळजी घेतात; शोध प्रोटोकॉल, काही क्लस्टर उत्पादने आणि एकच ब्रॉडकास्ट डोमेन अपेक्षणारे सर्व काही समीपतेची काळजी घेतात। चुकीच्या प्रकारची पोहोच पुनर्संचयित करणारा बॅकअप तांत्रिकदृष्ट्या जोडलेली पण प्रत्यक्षात निरुपयोगी अशी साइट तयार करतो।

ती यादी लिहून घ्या आणि डिझाइनला जोडा, कारण पहिल्या अनुप्रयोगाच्या मालकाला नवीन लिंकबद्दल कळताच उत्तर सहसा सरकते।

राउटेड फेलओव्हर: दोन प्रीफिक्स, एक पसंतीचा मार्ग

वेगवेगळ्या साइट प्रीफिक्ससह बॅकअप ही राउटिंगची समस्या बनते। प्रत्येक राउटरकडे रेडिओवरून पसंतीचा मार्ग आणि टनेलवरून कमी पसंतीचा मार्ग असतो, आणि रेडिओ रहदारी देणे थांबवतो तेव्हा पसंतीचा मार्ग मागे घेतला जातो। समोरच्या बाजूला स्वतःचा परतीचा मार्ग हवा, आणि दोन्ही बाजूंनी प्रत्येक दिशेने कोणता मार्ग पसंतीचा आहे हे मान्य केले पाहिजे, नाहीतर रहदारी फक्त एकाच दिशेने लांब वळण घेईल।

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

दुसऱ्याप्रमाणेच तिसरी कमांड वाचा: धोरण नियम, दुसरे तक्ते किंवा स्रोत-आधारित निर्णय एका सबनेटची रहदारी दुसऱ्यापेक्षा वेगळ्या पद्धतीने पाठवू शकतात, आणि एकच डीफॉल्ट शोध ते लपवतो।

ब्रिज केलेले फेलओव्हर: एक सेगमेंट, एक अडवणारा मार्ग

समीपता खरोखर आवश्यक असल्यास बॅकअपने इथरनेट फ्रेम वाहून नेणे आवश्यक आहे, जे राउटेड IP टनेल करत नाही। काही प्लॅटफॉर्म VPN इंटरफेस स्थानिक सेगमेंटमध्ये ब्रिज करण्यास आधार देतात, आणि ते इंटरफेस नंतर संबंधित परिणामांसह ब्रिज सदस्य बनतात। एकाच वेळी फॉरवर्ड करणारे दोन Layer 2 मार्ग लूप तयार करतात, म्हणून डिझाइनला दोन्ही साइट व्यापणारे स्पॅनिंग ट्री आणि कोणता मार्ग अडवावा याबद्दल स्पष्ट विधान आवश्यक आहे।

हे चेकबॉक्स नाही, महत्त्वाचा डिझाइन निर्णय आहे, आणि तुमच्या प्लॅटफॉर्मचे ब्रिजिंग दस्तऐवज, जसे की pfSense साठी ब्रिज विहंगावलोकन, VPN सदस्य प्रत्यक्षात कशात सहभागी होतो हे निश्चित करण्याचे ठिकाण आहे। एका असंबंधित उपकरणावर स्पॅनिंग-ट्री पर्याय सुरू करणे टोकापासून टोकापर्यंतच्या रचनेबद्दल काहीच सिद्ध करत नाही।

महत्त्वाच्या सीमेवर लक्ष ठेवा

वीज असलेला रेडिओ, वर आलेला इंटरफेस आणि निरोगी टनेल — प्रत्येक स्थानिक तथ्य सांगते। यापैकी कोणतेही एका इमारतीचे पॅकेट दुसऱ्यातील होस्टपर्यंत पोहोचले हे सिद्ध करत नाही, आणि फेलओव्हर लॉजिकने केवळ त्या तथ्यावर कार्य केले पाहिजे। धोरण परवानगी देत असल्यास दूरच्या राउटरच्या पलीकडील लक्ष्यावर लक्ष ठेवा, आणि असममित बिघाड दिसावा म्हणून दोन्ही दिशांचे स्वतंत्रपणे निरीक्षण करा।

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

तपासणी स्वस्त आणि मर्यादित ठेवा: लहान अंतराल, कमी संख्या आणि अनुप्रयोगाच्या सहनशीलतेशी जुळणारी मुदत। स्वतः ज्या मार्गाची चाचणी करतो त्यावर अवलंबून असलेला मॉनिटर काहीही कळवणे थांबवेपर्यंत यश कळवत राहील।

भाराखाली दोन्ही दिशांचा सराव करा

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

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

बिघाडाइतकीच काळजीपूर्वक पुनर्प्राप्तीची चाचणी करा। अस्थिर रेडिओ आत-बाहेर होत राहिला तर, पसंतीच्या लॉजिकमध्ये ओलसरपणा नसल्यास रहदारी इकडून तिकडे ओढेल, आणि वापरकर्ते त्याचा अनुभव एका स्वच्छ एकल बिघाडापेक्षा वाईट म्हणून करतात। प्रत्येक टप्प्यावर निवडलेला मार्ग, कोणत्या नवीन विनंत्या यशस्वी झाल्या आणि मार्ग बदलला तेव्हा उघड्या असलेल्या सत्रांना काय झाले हे नोंदवा। तीच नोंद दुसरे केबल ऑपरेशनल धोरणात बदलते।