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 सीमित गर्नुहोस् र ठूला अपडेट साँच्चै आउँछन् भनी पुष्टि गर्नुहोस्।
- साझा अण्डरले निर्भरताहरू सूचीबद्ध गर्नुहोस्, सुरुङको संख्या होइन।
- वास्तविक फिर्ता लिने समय नाप्नुहोस् र अनुप्रयोगले के गर्छ भनी टिप्नुहोस्।