दुई भवन, एउटा पोइन्ट-टु-पोइन्ट रेडियो र दोस्रो मार्ग बन्न सक्ने इन्टरनेट 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

विफलताजत्तिकै होसियारीसाथ पुनःप्राप्तिको परीक्षण गर्नुहोस्। अस्थिर रेडियो भित्र-बाहिर भइरहे पसन्दको लजिकमा ड्याम्पिङ नभए ट्राफिकलाई यताउता तान्छ, र प्रयोगकर्ताले त्यसलाई एउटा सफा एकल अवरोधभन्दा नराम्रो अनुभव गर्छन्। हरेक चरणमा छानिएको मार्ग, कुन नयाँ अनुरोध सफल भए र मार्ग बदलिँदा खुला रहेका सत्रहरूलाई के भयो टिप्नुहोस्। त्यही अभिलेखले दोस्रो केबललाई सञ्चालन नीति बनाउँछ।

सम्बन्धित लेखहरू