Cloud VPN का BGP ठेगानाहरू NIC मा होइन, टनेल भित्र हुन्छन्

VPN का लागि Cloud Router पृष्ठ खोल्नुहोस् र 169.254.0.0/16 भित्र ठेगाना भएको BGP सत्र तपाईंतिर हेर्दै छ। स्वाभाविक प्रतिक्रिया त्यो ठेगाना VM मा कतै राख्नु र सत्र माथि आउने पर्खाइ हो। त्यो प्रतिक्रिया विशिष्ट तरिकाले गलत छ: जोडी IPsec टनेलले बनाउने तार्किक लिङ्कको हो, मेसिनको साधारण नेटवर्क इन्टरफेसको होइन। NIC मा तपाईंले थप्ने कुनै पनि कुराले टनेललाई BGP बोक्न बाध्य पार्दैन।

जोडीलाई होस्टमा थप्नुको सट्टा स्ट्याकमा तल पछ्याउनुहोस्।

कन्सोलले जोडी देखाउने ठाउँबाट सुरु गर्नुहोस्

सत्र पृष्ठले Cloud Router को BGP ठेगाना र पीयर ठेगाना सूचीबद्ध गर्छ, IPv4 HA VPN का लागि दुवै link-local। तिनीहरूको छेउमा टनेल अन्त्य गर्ने बाह्य गेटवे ठेगानाहरू छन्। यी फरक वस्तुहरू हुन्: link-local जोडी भित्र बस्छ, र गेटवे ठेगानाहरू बाहिर बस्छन् र अरू केही काम गर्नुअघि तिनीहरू रुट गर्न योग्य हुनुपर्छ।

कन्फिगरेसन फाइल खोल्नुअघि तीनवटै लेख्नुहोस्, किनकि तिनलाई मिसाउनु नै सम्पूर्ण असफलता ढाँचा हो।

यसलाई बोक्ने टनेलसम्म तल जानुहोस्

दुई गेटवेबीच IPsec सुरक्षा संगठन भएपछि मात्र link-local जोडीको अर्थ हुन्छ। Google तर्फ HA VPN टनेलहरूले यसलाई दुई इन्टरफेसमा बनाउँछन्; तपाईंको तर्फ पीयरले वार्ता गरेको कुरा त्यही हो। पहिले swanctl --list-sas ले डाटा संगठन जाँच्नुहोस् र कुन टनेल कुन इन्टरफेसमा माथि छ लेख्नुहोस्, किनकि मृत टनेलमाथि स्वस्थ BGP सत्र असम्भव छ र आशावादी कन्फिगरेसन भएको मृत टनेल सामान्य कुरा हो।

BGP प्याकेट भित्री IP ट्राफिक हो। बाह्य नेटवर्कले यो कहिल्यै देख्दैन, त्यसैले कुनै स्विचलाई एउटै VLAN मा दुवै ठेगाना चाहिँदैन।

अब Linux पीयरलाई मिल्ने गरी कन्फिगर गर्नुहोस्

समर्थित टनेल डिजाइन छान्नुहोस् र भित्री ठेगानाहरू त्यसैले तय गरोस्। रुट आधारित इन्टरफेससँग, रुटिङ प्रविष्टि र वार्ता गरिएका ट्राफिक चयनकर्ताहरू सहमत हुनुपर्छ, किनकि इन्टरफेसको नाम मात्रले केही पनि अनुमति दिँदैन। BIRD लाई भित्री स्थानीय ठेगाना र Cloud Router को भित्री ठेगानातिर निर्देशित गर्नुहोस्, सत्र पृष्ठबाट AS नम्बरहरू सेट गर्नुहोस्, र सुरक्षित मार्गभित्र TCP 179 लाई अनुमति दिनुहोस्। टाढाको बाह्य ठेगानातर्फको रुट भौतिक अपलिङ्कमा राख्नुहोस् ताकि टनेलले आफ्नै यातायात समात्न नपाओस्।

आफैलाई रुट गर्ने टनेल ह्यान्डशेकसहितको लूप हो, र एक घण्टा यो फायरवाल समस्याजस्तो देखिन्छ।

हरेक चरण क्रममा जाँच्नुहोस्, सबै कुरा एकैचोटि होइन

चरणहरू पार गर्नुहोस्: सुरक्षा संगठन माथि, टनेल ठेगानाबाट भित्री पीयर पुग्न योग्य, BGP सत्र स्थापित, प्रिफिक्सहरू स्वीकृत, त्यसपछि कार्यभार प्रिफिक्स साँच्चै प्रयोग भएको। birdc show protocols तेस्रो प्रश्नको जवाफ दिन्छ र अरू केही होइन, त्यसैले मानिसहरू चाँडै विजय घोषणा गर्छन्।

स्थापित छिमेकीले दुवै पक्षले तपाईंलाई चाहिने प्रिफिक्सहरू घोषणा गरे भनी वा ती रुटहरू प्राथमिकताका रूपमा स्थापित भए भनी ग्यारेन्टी दिँदैन।

यदि सत्र स्थापित छ र ट्राफिक अझै गलत बाटो लिन्छ भने, घोषित प्रिफिक्सहरूलाई रुटिङ तालिकाले तिनीसँग के गर्छ भन्नेसँग तुलना गर्नुहोस्. अन्यत्र अझ विशिष्ट रुट, वा अर्को बाटोलाई प्राथमिकता, तपाईंलाई काम गर्ने BGP सत्र दिन्छ र कुनै उपयोगी फर्वार्डिङ दिँदैन।

यसलाई Router Appliance मा लागू गर्नुअघि रोकिनुहोस्

Network Connectivity Center Router Appliance फरक जोडाइ मोडेल हो। यसका Cloud Router पीयरहरूले HA VPN को link-local जोडीको सट्टा VPC र सबनेट व्यवस्थाबाट आन्तरिक ठेगानाहरू प्रयोग गर्छन्। यदि साँचो लक्ष्य रुटिङ VM सँग BGP हो भने, link-local सत्र प्रतिलिपि गर्नुको सट्टा त्यो उत्पादनको इन्टरफेस आवश्यकताहरू पालना गर्नुहोस्।

link-local दायराले अझै भन्छ त्यही अर्थ दिन्छ। तार्किक टनेलले यो छिमेकीपन प्रदान गर्छ, र यसले VPC भरि मनपरी link-local गन्तव्यहरू रुट गर्न इजाजत दिँदैन।