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 मर्यादित करा आणि मोठे अपडेट खरोखर येतात याची खात्री करा।
- सामायिक अंडरले अवलंबित्वांची यादी द्या, बोगद्यांची संख्या नाही।
- प्रत्यक्ष मागे घेण्याची वेळ मोजा आणि अनुप्रयोग काय करतो ते नोंदवा।