VPN पर BGP आपके अंडरले पथ को क्यों नियंत्रित नहीं करता
VPN पर BGP पहुँच-योग्यता का आदान-प्रदान करता है और रूट नीति लागू करता है, पर अंडरले फिर भी बाहरी पथ चुनता है। सत्र वास्तव में क्या नियंत्रित करता है।
दो साइटें IPsec सुरंग पर BGP पीयर करती हैं, एक-दूसरे के प्रीफ़िक्स सीखती हैं, और आरेख को पथ नियंत्रण के रूप में फिर से लेबल किया जाता है। यही लेबल भ्रम की शुरुआत है। सत्र पहुँच-योग्यता का आदान-प्रदान करता है और नीति लागू करता है, पर इसमें कोई कहने का अधिकार नहीं है कि कौन सा प्रदाता, केबल या राउटर एन्क्रिप्टेड पैकेट ले जाता है। मैंने एक टीम को काम करती सुरंग फिर से बनाते देखा है, क्योंकि उन्हें उम्मीद थी कि BGP रूट परिवर्तन ट्रैफ़िक को किसी दूसरे फ़ाइबर पथ पर ले जाएगा जिसे सत्र कभी प्रभावित नहीं कर सकता था।
लोग क्या मानते हैं कि सत्र क्या खरीदता है
ज़्यादातर अपेक्षा इससे आती है कि प्रयोगशाला में रूट परिवर्तन कैसा दिखता है। आप सुरंग पर एक प्रीफ़िक्स की घोषणा करते हैं, दूर का पक्ष उसे स्थापित करता है, और ट्रैफ़िक चलता है। यही क्रम उस राउटर पर भी होता है जिसमें वास्तव में ट्रैफ़िक-इंजीनियरिंग के नियंत्रण हैं, इसलिए दोनों को मिला दिया जाता है। प्रयोगशाला में दोनों साइटें आमतौर पर एक ही एक्सेस लिंक साझा करती हैं, और ठीक इसी कारण अंतर वहाँ कभी नहीं दिखता।
BGP एक पहुँच-योग्यता प्रोटोकॉल है। यह पीयर को बताता है कि आप किसी प्रीफ़िक्स के लिए पैकेट पहुँचा सकते हैं और हर पक्ष को मिलने वाले प्रस्तावों को क्रम में रखने देता है। यह सुरंग के पार वास्तव में उपयोगी है: साइटों के आने-जाने के साथ प्रीफ़िक्स दिखते और गायब होते हैं, और आप हर एज उपकरण पर स्थिर रूट लिखे बिना किसी रेंज को अस्वीकार कर सकते हैं। जो यह नहीं करता, वह है किसी प्रदाता के राउटर को आपके नियंत्रण में लाना।
अंडरले बाहरी हेडर ले जाता है। आपका सुरंग एंडपॉइंट एन्क्रिप्टेड पैकेट पीयर पते पर भेजता है, और उन दो पतों के बीच का नेटवर्क उन्हें उन रूटों से अग्रेषित करता है जो उसके ऑपरेटरों ने स्थापित किए हैं। BGP सत्र में कुछ भी उस निर्णय को नहीं बदलता, जब तक वही प्रदाता ऐसी समर्थित सेवा न दे जो ऐसा करती हो।
सत्र वास्तव में क्या ले जाता है
BGP वक्ता अपने पीयर पर पोर्ट 179 पर TCP कनेक्शन खोलता है, RFC 4271 में परिभाषित संदेश प्रारूपों और पथ विशेषताओं का उपयोग करते हुए। जब पीयर पता सुरंग के भीतर होता है, तो सत्र शुरू होने से पहले सुरंग ऊपर होनी चाहिए और वह पता पहुँच-योग्य होना चाहिए। पूरा हुआ IKE आदान-प्रदान BGP पड़ोसी नहीं है। रूट-आधारित IPsec कार्यान्वयन केवल तब ट्रैफ़िक पास करते हैं जब मेल खाता सुरंग रूट मौजूद हो, और नीति-आधारित कार्यान्वयन को संरक्षित सिलेक्टर के भीतर पीयर पता चाहिए। इसे उलटा करने से वह क्लासिक स्थिति बनती है जिसमें सुरंग हरी है और सत्र निष्क्रिय बैठा है।
सत्र ऊपर होने के बाद, नीति तय करती है कि उसे क्या पार करेगा। प्रीफ़िक्स सूचियाँ, AS-पथ फ़िल्टर, अधिकतम प्रीफ़िक्स की सीमा और डिफ़ॉल्ट रूटों के बारे में स्पष्ट निर्णय न्यूनतम हैं, और वे दोनों दिशाओं में लागू होते हैं। जो पीयर जो कुछ मिलता है सब स्वीकार करता है, वह आपको ऐसा डिफ़ॉल्ट रूट दे सकता है जो स्थानीय इंटरनेट पहुँच को चुपचाप बदल दे। दोनों दिशाओं के लिए अलग सूचियाँ चाहिए, क्योंकि पीयर से आप क्या स्वीकार करते हैं और उसे क्या घोषित करते हैं, ये अलग निर्णय हैं।
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
आगे MTU काटता है। एन्कैप्सुलेशन उपयोगी पेलोड घटा देता है, इसलिए बड़ा अपडेट ऐसे सत्र को अटका सकता है जो पूरी तरह स्थापित दिखता है: पीयर ऊपर रहता है, प्रीफ़िक्स कभी नहीं आते, और लॉग में कुछ स्पष्ट नहीं पड़ता। फ़िल्टरों को दोष देने से पहले सुरंग इंटरफ़ेस पर TCP MSS सीमित करें, या ओवरहेड के लिए जगह के साथ सुरंग MTU सेट करें।
बाहरी पैकेट अभी भी कहाँ जाते हैं
एक साइट से दूसरी साइट तक एन्क्रिप्टेड पैकेट उसी रास्ते से निकलते हैं जो स्थानीय राउटर पीयर के सार्वजनिक पते के लिए चुनता है। अगर दोनों साइटें एक ही प्रदाता से ट्रांज़िट खरीदती हैं, एक ही मेट्रो सुविधा पार करती हैं, या एक पक्ष कैरियर-ग्रेड NAT के पीछे है, तो सुरंग प्रदाता विफलता से केवल संयोग से बचती है। निगरानी उपकरण में सुरंग आइकन गिनने से आपको इस बारे में कुछ पता नहीं चलता।
रूट चयन और फ़ॉरवर्डिंग स्थापना भी अलग घटनाएँ हैं। कोई प्रीफ़िक्स BGP तालिका में सर्वश्रेष्ठ के रूप में बैठ सकता है और फिर भी फ़ॉरवर्डिंग तालिका से गायब हो सकता है, क्योंकि अगला हॉप हल नहीं हो सकता या कोई अधिक विशिष्ट रूट जीत जाता है। जब कोई बताता है कि BGP ने प्रीफ़िक्स सीखा पर ट्रैफ़िक नहीं बहता, तो उपयोगी प्रश्न यह है कि क्या वह स्थापित है और किस अगले हॉप की ओर इशारा करता है।
डिज़ाइन समीक्षा के लिए ईमानदार उत्तर साझा निर्भरताओं की सूची है: एक्सेस सर्किट, अपस्ट्रीम प्रदाता, सुविधा और वापसी पथ पर कोई भी स्टेटफ़ुल उपकरण। सुरंग के पार का सत्र ऐसी निर्भरता नहीं हटा सकता जिसके ऊपर वह नहीं बैठा है।
अलग करने योग्य तीन निर्णय
जब कोई डिज़ाइन इन्हें मिला देता है, तो हर आउटेज बातचीत गोल घूमती है। पहले इन्हें कागज़ पर अलग करें, फिर हर एक को उस उपकरण से जोड़ें जो वास्तव में उसे लागू करता है।
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
हर पंक्ति का मालिक अलग है। पहली बातचीत है, दूसरी आपके उपकरणों पर कॉन्फ़िगरेशन है, तीसरी ज़्यादातर किसी और का नेटवर्क है। जो परिवर्तन अनुरोध अपनी छूने वाली पंक्ति का नाम लेता है, उसे स्वीकृत करना उस अनुरोध से कहीं आसान है जो BGP समस्या कहता है।
योजना बनाने योग्य विफलता के प्रकार
पीयर का सारांश रूट स्वीकार करना सबसे आम स्व-प्रेरित घाव है। कोई आदान-प्रदान सरल बनाने के लिए छोटा एग्रीगेट घोषित करता है, दूर का पक्ष उसे स्वीकार कर लेता है, और सुरंग के पीछे न होने वाली रेंजों का ट्रैफ़िक सुरंग का अनुसरण करके मर जाता है। ठीक अपेक्षित प्रीफ़िक्स पर फ़िल्टर करें, या सही सीमाओं वाली प्रीफ़िक्स सूची का उपयोग करें, और कभी नंगा एग्रीगेट स्वीकार न करें क्योंकि वह सत्र को साफ़-सुथरा दिखाता है।
वापसी का समय दूसरा है। पहचान होल्ड टाइमर, आपने सक्षम किया हो तो BFD, सुरंग डेड-पीयर पहचान और दूर का पक्ष कितनी जल्दी घोषणा बंद करता है, पर निर्भर करती है। मौजूदा सत्र अलग समस्या हैं: नया रूट नए कनेक्शन बहाल कर सकता है जबकि स्थापित TCP सत्र पुराने पते इस्तेमाल करते रहते हैं, और पथ पर स्टेटफ़ुल फ़ायरवॉल या NAT ऐसी प्रविष्टियाँ रख सकते हैं जो अब मेल नहीं खातीं। रूट परिवर्तन सब कुछ सुलझा देगा मानने के बजाय एप्लिकेशन रिकवरी को स्वीकृति मानदंड में रखें।
तीसरा है वापसी पथ की असमरूपता। ट्रैफ़िक सुरंग से आ सकता है और ऐसे प्रदाता लिंक से लौट सकता है जो कभी उसे ले जाने के लिए बना ही नहीं था, जो एकतरफ़ा ऑडियो, विफल हैंडशेक या जवाब गिराने वाले फ़ायरवॉल के रूप में दिखता है। दोनों दिशाएँ अलग-अलग जाँचें।
अनुबंध में क्या लिखें, और इसे कैसे सत्यापित करें
अनुमत प्रीफ़िक्स लिखित में माँगें: किसे हर रेंज उत्पन्न करने का अधिकार है, डिफ़ॉल्ट रूट अनुमत है या नहीं, और सुरंग सेवा किन पता परिवारों का समर्थन करती है। RFC 8212 ने स्पष्ट आयात और निर्यात नीति को उन कार्यान्वयनों में eBGP के लिए अपेक्षा बना दिया जो उसका पालन करते हैं, इसलिए जो पीयर अभी भी निहित सब-स्वीकार व्यवहार पर निर्भर है, उससे पूछना उचित है।
फिर आरेख के बजाय उपकरण से सत्यापित करें। FRR-शैली के राउटर पर उपयोगी कमांड:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
दो अवलोकन जोड़ें जो रूटिंग तालिका आपको नहीं दे सकती। यह पुष्टि करने के लिए बाहरी इंटरफ़ेस पर कैप्चर करें कि एन्कैप्सुलेटेड पैकेट वास्तव में किस पते को लक्षित करते हैं, उदाहरण के लिए tcpdump -ni eth0 udp port 51820 WireGuard सुरंग के लिए, या IPsec के लिए ESP फ़िल्टर। फिर पीयर के सार्वजनिक पते की ओर ट्रेस करें और सुरंग के भीतर के ट्रेस से हॉपों की तुलना करें; अगर दोनों एक ही प्रदाता श्रृंखला का पालन करते हैं, तो आपकी अनावश्यकता नेटवर्क में नहीं, रूटिंग नीति में रहती है।
अंत में, जानबूझकर वापसी का परीक्षण करें। रखरखाव विंडो के दौरान सुरंग नीचे उतारें, दर्ज करें कि प्रीफ़िक्स कितने समय तक स्थापित रहता है, मौजूदा सत्रों का क्या होता है, और दूर का पक्ष ऐसे रूट पर लौटता है या नहीं जिसे आप वास्तव में स्वीकार करते। वह अभ्यास किसी भी आरेख से डिज़ाइन के बारे में अधिक कहता है।
रूट अनुमति नहीं है। आप जिन प्रीफ़िक्स का आदान-प्रदान तय करते हैं, वे इस बारे में कुछ नहीं कहते कि कौन से उपयोगकर्ता सुरंग के पीछे किस सेवा तक पहुँच सकते हैं, इसलिए प्रमाणीकरण, अनुमत सेवाएँ और होस्ट फ़ायरवॉल ठीक वहीं रखें जहाँ थे। पहुँच-योग्य पीयर भी असीमित ट्रांज़िट या मनमाने पते उत्पन्न करने की अनुमति नहीं है, और ऐसा अधिकार BGP नीति पंक्ति में नहीं, अनुबंध में वाणिज्यिक प्रश्न के रूप में होना चाहिए।
- हर पक्ष जिन प्रीफ़िक्स को उत्पन्न कर सकता है और जिन्हें कभी स्वीकार नहीं करना चाहिए, उनके नाम बताएं।
- सुरंग पर MSS सीमित करें और पुष्टि करें कि बड़े अपडेट वास्तव में आते हैं।
- साझा अंडरले निर्भरताओं की सूची दें, सुरंगों की संख्या नहीं।
- वास्तविक वापसी का समय मापें और नोट करें कि एप्लिकेशन क्या करता है।