क्लाउड VPN लाई BGP चाहिन्छ: अन्य राउटिङ प्रोटोकलहरू किन असफल हुन्छन्

IPsec सुरक्षा सम्बन्ध चालु छ, टनेलका काउन्टर चलिरहेका छन्, र क्लाउड प्रिफिक्सतर्फको ट्राफिक हराउँछ। त्यसपछि अपरेटरले ग्राहक राउटरमा OSPF सक्षम गर्न खोज्छ, छिमेकी बन्ने आशा गर्छ, र केही हुँदैन। टनेल कहिल्यै हराएको भाग थिएन: व्यवस्थापित क्लाउड VPN ले परिभाषित राउटिङ सम्झौता दिन्छ, र ठूला प्लेटफर्महरूमा त्यो सम्झौता BGP हो। सत्र नबनी र प्रिफिक्स स्वीकार नगरेसम्म टनेल पछाडि कुनै गन्तव्य नभएको इन्क्रिप्टेड बाटो मात्र हो।

टनेल चालु छ र बाटो हराएको छ

चरण 1 र चरण 2 पूरा हुनुले दुई पक्ष सुरक्षामा सहमत छन् भन्ने प्रमाणित गर्छ, तर कुनै पक्षलाई ट्राफिक कहाँ पठाउने भन्ने थाहा छ भन्ने होइन। यी फरक असफलता विधि भएका फरक स्थिति मेसिन हुन्।

क्रममा तीन प्रश्न सोध्नुहोस्: प्रिफिक्स घोषणा भएको थियो, छिमेकीले स्वीकार गरेको थियो, र फर्वार्डिङका लागि स्थापना भएको थियो? घोषणा भई फिल्टर भएको प्रिफिक्स नीति समस्या हो। कहिल्यै घोषणा नभएको प्रिफिक्स सत्र वा कन्फिगरेसन समस्या हो। स्वीकार भई स्थापना नभएको प्रिफिक्स रुट छनोट समस्या हो, र प्रत्येक उत्तरले कन्फिगरेसनको फरक भागतर्फ संकेत गर्छ।

प्रदायकले वास्तवमा के दिन्छ

व्यवस्थापित VPN गेटवे असीमित राउटर होइन। प्रदायकले समर्थित छिमेकी ठेगाना, स्वायत्त प्रणाली सेटिङ, प्रिफिक्स सीमा र परिभाषित असफलता व्यवहार भएको गेटवे दिन्छ। त्यही सतह उत्पादन हो।

Google Cloud ले HA VPN का लागि गतिशील BGP राउटिङको दस्तावेज गर्छ, जसमा Cloud Router छिमेकी रुट सिक्छ र VPC लाई योग्य अनुकूलित गतिशील रुट आपूर्ति गर्छ। AWS Site-to-Site VPN ले स्थिर र गतिशील राउटिङबीचको छनोटको दस्तावेज गर्छ, र BGP जीवन्तता जाँचलाई टनेल फेलओभरका लागि उपयोगी बताउँछ, साथै BGP नभएका उपकरणका लागि स्वास्थ्य जाँच पनि समर्थन गर्छ। कुनै पनि प्लेटफर्मको व्यवहार अर्कोको उत्पादन नामबाट अनुमान गर्नु हुँदैन।

व्यावहारिक परिणाम के हो भने तपाईं पहिले व्यवस्थापित मोड छान्नुहुन्छ, त्यसपछि समर्थित प्यारामिटर पढ्नुहुन्छ। सेवाले नदिने छिमेक प्रकार मान्ने डिजाइन ग्राहक राउटरमा समाधान गर्ने कन्फिगरेसन समस्या होइन।

टनेल सुरक्षा र पहुँच फरक काम हुन्

IPsec ले टनेलका लागि छानिएको ट्राफिकको सुरक्षा गर्छ। BGP ले प्रिफिक्सलाई योग्य बनाउने पहुँच जानकारी दिन्छ। चलिरहेको टनेलले अपेक्षित प्रिफिक्स घोषणा, स्वीकृत वा स्थापित भएको प्रमाणित गर्दैन।

दुई योग्य टनेल बाटोबाट 10.42.0.0/16 घोषणा गर्ने शाखाको कल्पना गर्नुहोस्। एउटा प्रयोगयोग्य बाटो हटाउनुहोस् र प्रत्येक कार्यभारको रुट कसैले सम्पादन नगरी रुट छनोट बदलिन सक्छ। पहिचान, रुट छनोट र अनुप्रयोग पुनःप्राप्ति तत्काल होइनन्, र तैनाथीहरूमा समान छैनन्, त्यसैले फेलओभर परीक्षणले सम्पूर्ण क्रम हेर्नुपर्छ, पहिलो प्याकेट होइन जो पार हुन्छ।

क्लाउड प्रिफिक्स पहुँचभन्दा बाहिर हुँदा, क्रिप्टो छुनुअघि सत्र स्थिति र सिकेका रुट जाँच्नुहोस्। पछाडि रुट नभएको चालु SA यो लक्षणको सबैभन्दा सामान्य रूप हो।

OSPF का मान्यताहरू कहाँ टुट्छन्

IPsec टनेलभित्र OSPF, IS-IS वा अर्को प्रोटोकल स्व-व्यवस्थापित उपकरणमा पूर्ण रूपमा सम्भव छ, जहाँ दुवै छेउ र फर्वार्डिङ डिजाइन तपाईंको हो। त्यो तथ्यले गतिशील राउटिङ मोडका रूपमा मात्र BGP दिने व्यवस्थापित सेवाबारे केही भन्दैन।

यदि प्रस्तावित डिजाइनलाई सेवाले समर्थन नगर्ने छिमेक-सम्बन्ध चाहिन्छ भने, वास्तुकला जानाजान परिवर्तन गर्नुहोस्। विकल्पहरूमा VPC मा स्व-व्यवस्थापित उपकरण, सेवाले समर्थन गर्ने ठाउँमा स्थिर राउटिङ, वा फरक कनेक्टिभिटी उत्पादन समावेश छन्। ग्राहक राउटरमा मात्र प्रोटोकल कन्फिगर गर्दा क्लाउडतर्फ नभएको छिमेकी थप्न सकिँदैन, र प्रिफिक्स देखा पर्ने छैन।

एक विक्रेताको उत्तर अर्कोको गेटवेमा नलैजानुहोस्। गतिशील राउटिङ वा टनेल फेलओभर जस्ता एउटै शब्दहरूले फरक संयन्त्र र फरक सीमा वर्णन गर्न सक्छन्।

सेवाको आवश्यकता पढ्नुहोस्, त्यसपछि डिजाइन गर्नुहोस्

पहिलो कन्फिगरेसन लाइनअघि छिमेकी ठेगाना, स्वायत्त प्रणाली नम्बर, तपाईंले घोषणा र स्वीकार गर्ने प्रिफिक्स, रुट सीमा र टनेल असफल हुँदा अपेक्षित व्यवहार लेख्नुहोस्। ती पाँच बुँदा नै तपाईंले डिजाइन गर्ने सम्झौता हुन्।

त्यसपछि त्यही क्रममा प्रमाणित गर्नुहोस्: सत्र स्थापित, प्रिफिक्स प्राप्त, VPC रुट तालिकामा रुट उपस्थित, र सेवा ठेगानातर्फ वास्तविक प्रवाह। जबरजस्ती फेलओभरपछि दोहोर्याउनुहोस्, किनकि पुनः स्थापित हुने सत्र फरक रुट सेटसँग फर्किन सक्छ। डिजाइन सेकेन्डभन्दा कम अभिसरणमा निर्भर छ भने, अनुमान गर्नुको सट्टा नाप्नुहोस्।

परिवर्तन अभिलेखसँगै सेवा सम्झौता राख्नुहोस्। पछि कसैले टनेलले OSPF किन चलाउन सक्दैन भनी सोध्दा, उत्तर प्रोटोकल सीमा होइन, उत्पादन सीमा हो, र अभिलेखमा त्यो लेखिएको हुनुपर्छ।