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 किमान एका होल्ड टाइमरपर्यंत सुरू ठेवा।
काहीही बदलण्यापूर्वी या पाच मुद्द्यांची पुष्टी करा: प्रीफिक्स स्थिर आहे की हलत आहे, दोन्ही टोकांवर पुढील हॉप टनेलकडे दाखवतो का, हॉप संख्या पुनरावृत्ती होते का, एकच साइट प्रीफिक्सची मालक आहे का, आणि बदल सहन करणारा व्यवस्थापन मार्ग तुमच्याकडे आहे का। पाचपैकी एकही अज्ञात असेल तर उर्वरित चार अंदाज आहेत।