VPN साइटहरूमा राउटिङ लुप र रुट फ्ल्यापिङबीच फरक कसरी पहिचान गर्ने
राउटिङ लुप र फ्ल्यापिङ रुटले उही अन्तराल भएको क्षति निम्त्याउँछन्। गेटवेहरूमा तीन जाँचले केही परिवर्तन गर्नुअघि तिनीहरूलाई छुट्याउँछ।
दुई साइट, एउटा टनेल र केही समय जवाफ दिएर त्यसपछि चुप बस्ने एक टाढाको प्रिफिक्स। पहिलो प्रतिक्रिया त्यसलाई राउटिङ लुप भन्ने हुन्छ, र कहिलेकाहीँ त्यो ठ्याक्कै त्यही हुन्छ। तर लुप र फ्ल्यापिङ रुटले उही गुनासो उत्पन्न गर्छन्, र तिनलाई विपरीत मर्मत चाहिन्छ: एउटा कहिल्यै नसकिने फर्वार्डिङ निर्णय हो, अर्को टेबल छोडिरहने प्रिफिक्स हो। तीन अवलोकनले तिनलाई छुट्याउँछन्, र फिल्टर छुनु वा टनेल पुनः सुरु गर्नुअघि तीनवटै गेटवेको कमाण्ड लाइनबाट जम्मा गर्न सकिन्छ।
लुप हप अनुसार निर्धारण हुन्छ। साइट A ले गन्तव्यका लागि B लाई अर्को हप छान्छ, B ले त्यही गन्तव्यका लागि A लाई छान्छ, र प्याकेट दुई चक्करपछि TTL मा सकिन्छ। फ्ल्यापिङ भने राउटिङ प्रोटोकलले निर्धारण गर्छ: प्रिफिक्स फिर्ता लिइन्छ, पुनः स्थापना गरिन्छ वा वैकल्पिक अर्को हपले प्रतिस्थापन गरिन्छ, त्यसैले केही प्याकेटसँग रुट नै हुँदैन भने अरू पूर्ण रूपमा राम्रो रुट पछ्याउँछन्।
प्रश्न टुंग्याउने तीन जाँच
पहिलो निर्णयका लागि प्याकेट क्याप्चर आवश्यक छैन। दुवै छेउमा प्रिफिक्सको अवस्था, प्रत्येक पक्षले छान्ने अर्को हप, र दोहोरिने वा नदोहोरिने हप संख्या चाहिन्छ। ट्राफिक असफल हुँदा प्रिफिक्स उही अर्को हपसँग स्थापित रह्यो भने लुप फर्वार्डिङ मार्गमै हुन्छ। प्रिफिक्स हराएर फर्कियो भने दोष फर्वार्डिङमाथि हुन्छ र मर्मत राउटिङ प्रोटोकलको हो, स्थिर रुटको होइन।
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
सुरु गर्नुअघि एउटा चेतावनी। यदि तपाईं यो लुप भइरहेको टनेलबाट पढ्दै हुनुहुन्छ भने रुट बदल्ने क्षणमै तपाईंको सत्र मर्छ। तपाईंले मर्मत गर्न लागेको प्रिफिक्समा निर्भर नहुने कन्सोल वा व्यवस्थापन मार्ग खोल्नुहोस्।
पहिलो जाँच: प्रिफिक्स स्थिर छ कि हल्लिरहेको छ
कन्फिगरेसन फाइलले के वाचा गर्छ भनेर होइन, कर्नेलले के स्थापना गर्यो भनेर सोध्नुहोस्। लिनक्स गेटवेमा ip route get 10.20.30.40 ले फर्वार्डिङ मार्गले गर्ने त्यही खोज नीति तालिकासमेत गर्छ, भने ip route show 10.20.30.0/24 ले प्रविष्टि आफैँ देखाउँछ। ip monitor route ले प्रत्येक परिवर्तन हुने क्षणमै प्रसारण गर्छ, र प्रिफिक्स आउँदै-जाँदै देख्ने सबैभन्दा छिटो उपाय त्यही हो।
FRR वा BIRD चल्ने राउटरमा चाखलाग्दो कुरा फर्वार्डिङ टेबल होइन। show ip bgp 10.20.30.0/24 ले छानिएको मार्ग र त्यसको अपटाइम फर्काउँछ; हरेक केही मिनेटमा रिसेट हुने अपटाइम भनेको नाम दिन सकिने फ्ल्यापिङ हो, लुप होइन। show ip bgp summary ले छिमेकीको अवस्था र प्रिफिक्स संख्या देखाउँछ, त्यसैले बारम्बार खस्ने साथीले फर्वार्डिङ मार्गबाट दोष हटाउँछ।
केही बदल्नुअघि उत्तर लेख्नुहोस्। पिङ असफल हुँदा दस मिनेट स्थिर रहनु, र दस मिनेटमा चार पटक हराउनु फरक फरक अर्को कदमतर्फ लैजान्छ। दोस्रोले स्थिर रुटका सबै सिद्धान्तलाई अप्रासंगिक बनाउँछ।
दोस्रो जाँच: अर्को हप आगमन टनेलतिर फर्केर देखाउँछ कि
लुपका लागि दुई गेटवेको सहमति चाहिन्छ। प्याकेट प्राप्त गर्ने साइटमा प्याकेट बाहिर जान प्रयोग गर्ने मार्ग हेर्नुहोस्: वास्तविक स्रोत ठेगानासहित ip route get 10.20.30.40 from 10.10.5.20, किनभने नीति नियमले मुख्य तालिकाभन्दा फरक जवाफ दिन सक्छ। त्यसपछि पठाउने साइटमा खोज दोहोर्याउनुहोस्। प्रत्येक पक्षले उही प्रिफिक्सका लागि अर्कोलाई अर्को हप छान्यो भने लुप प्रमाणित हुन्छ र कुनै क्याप्चरले केही थप्दैन।
कारण प्रायः सधैं टनेल पार गर्नु नहुने घोषणा हुन्छ। टनेलमा पुनर्वितरण गरिएको पूर्वनिर्धारित रुट, टाढाको साइटको आफ्नै सबनेट ढाक्ने समग्र, वा सावधानीका लागि साथीतिर देखाउने स्थिर रुट — सबैले उही पारस्परिक अर्को हप बनाउँछन्। टनेल पूर्ण रूपमा स्थापित भएर पनि ट्राफिक वृत्तमा बोक्न सक्छ; strongSwan का फर्वार्डिङ नोटहरू त्यो आवश्यकताको राउटिङ पक्ष वर्णन गर्छन्।
WireGuard आफ्नै नोटको योग्य छ, किनभने दोष दिने कुनै घोषणा छैन। wg show ले प्रत्येक साथीको AllowedIPs सूचीबद्ध गर्छ, र कर्नेलले साथीका लागि गन्तव्य त्यो दायराभित्र परेमा मात्र स्वीकार्छ। त्यहाँको लुप भनेको एकअर्कामा पर्ने AllowedIPs दायरा वा इन्टरफेसभित्र फर्केर देखाउने स्थिर रुट हो, त्यसैले मर्मत ती दुई ठाउँमा मात्र हुन्छ।
तेस्रो जाँच: हप संख्या पढ्नुहोस्, ताराहरू होइन
traceroute -n -I 10.20.30.40 र mtr -n -r -c 20 10.20.30.40 दुवैले मार्ग देखाउँछन्, र ICMP मोड प्रायः UDP प्रोब खाने फिल्टरिङबाट बाँच्छ। लुप उही दुई गेटवे ठेगानाको छोटो दोहोरिने क्रमजस्तो देखिन्छ, हरेक पटक TTL बढ्दै जान्छ। खस्किनु भनेको अन्तिम जवाफ दिने गेटवेपछिका ताराहरूजस्तो देखिन्छ, र एउटै मौन हप कुनै कुराको प्रमाण होइन।
मार्ग अस्पष्ट हुँदा तारमै TTL पढ्नुहोस्। दुवै गेटवेमा tcpdump -ni any -vv icmp ले प्रत्येक प्याकेटको TTL र समय नाघेको प्रत्येक जवाफको स्रोत ठेगाना देखाउँछ। प्याकेटले मार्गमा हुन सक्ने हप संख्याभन्दा कम TTL सहित टाढाको साइटमा पुग्यो भने traceroute ले नदेखाउने हप कतैले थपिरहेको छ, र एक साइटको फायरवालले अर्काको तर्फबाट प्रोबको जवाफ दिँदा यो हुन्छ।
प्रिफिक्सको मालिक मर्मत गर्नुहोस्, त्यसपछि दुवै दिशा जाँच्नुहोस्
कुन साइटले गन्तव्य उत्पन्न गर्छ र कुन ट्रान्जिट मार्ग अनुमति छन् भन्ने निर्णय गरेर त्यस मालिकको घोषणा वा स्थिर रुट बदल्नुहोस्। प्राप्त गर्ने साइट सुधार्नु लोभलाग्दो र प्रायः गलत हुन्छ: यसले एउटा प्रिफिक्सको लुप लुकाउँछ र अर्कोका लागि खराब घोषणा ठाउँमै छोड्छ। रुट ट्याग, वितरण सूची र split-horizon नियमहरू यसलाई स्रोतमै रोक्नका लागि छन्, र ती एउटै प्रिफिक्ससँग मिल्ने फिल्टरभन्दा सस्तो छन्।
परिवर्तनपछि जाने र फर्किने दिशा छुट्टाछुट्टै जाँच्नुहोस्, किनभने लक्षणमा देखिने सुधार नहुँदै लुप कालो प्वालले प्रतिस्थापित हुन सक्छ। दुवै छेउबाट ip route get चलाउनुहोस्, गेटवे नभएको होस्टबाट ट्राफिक पठाउनुहोस्, र फ्ल्यापिङलाई मर्मत ठान्न नदिन ip monitor route कम्तीमा एउटा होल्ड टाइमरसम्म चलिरहन दिनुहोस्।
केही बदल्नुअघि यी पाँच बुँदा पुष्टि गर्नुहोस्: प्रिफिक्स स्थिर छ कि हल्लिरहेको छ, दुवै छेउको अर्को हप टनेलतिर देखाउँछ कि, हप संख्या दोहोरिन्छ कि, एउटै साइट प्रिफिक्सको मालिक हो कि, र परिवर्तन सहने व्यवस्थापन मार्ग तपाईंसँग छ कि। पाँचमध्ये एउटा पनि अज्ञात भए बाँकी चार अनुमान हुन्।