GCP HA VPN: BGP सत्र Waiting for peer मा अड्किन्छ, ठेगाना जोडीको अदलबदल
Cloud VPN BGP सत्र Waiting for peer मा अड्किएको छ भने प्रायः टनेल र पियरका ठेगाना अदलबदल भएका हुन्छन्। केही पनि पुनः निर्माण गर्नुअघि जोडी जाँच्नुहोस्।
Cloud VPN टनेलमा कहिल्यै Established मा नपुग्ने BGP सत्र प्रायः राउटिङको समस्या होइन। यो वायरिङको समस्या हो: एकअर्काको प्रतिबिम्ब हुनुपर्ने दुई ठेगाना गलत क्रममा राखिएका छन्, वा पहिलो टनेलको जोडी दोस्रोमा फेरि प्रयोग गरिएको छ। टनेल आफैं पूर्ण रूपमा स्वस्थ हुन सक्छ जबकि सत्र Waiting for peer मा बसिरहन्छ, किनभने IPsec र BGP ती एउटै दुई अन्त्य बिन्दुबीचका छुट्टाछुट्टै वार्ता हुन्। केही पनि पुनः निर्माण गर्नुअघि यी दुईमध्ये कुन बिग्रिएको छ निर्णय गर्नुहोस्।
एउटा प्रश्नले अधिकांश अवस्था टुंग्याउँछ: पियर उपकरणले Cloud Router को ठेगाना देख्छ नै?
टनेलको अवस्था र सत्रको अवस्था फरक जाँच हुन्
पहिले IKE र ESP आउँछन्। टनेल स्थापित भएको छैन भने भित्रको कुराले अर्थ राख्दैन र BGP ठेगानाको बहस चाँडो हुन्छ। टनेलको स्थिति र विस्तृत स्थिति पढ्नुहोस्, त्यसपछि त्यही टनेलका लागि राउटरको BGP पियर स्थिति पढ्नुहोस्।
टनेल चालु छ तर यसको BGP पियर बन्द छ भने त्रुटि सत्रमा सीमित हुन्छ: पियर ठेगाना, ASN वा भित्री ठेगानामा आउने TCP 179. टनेल चालु, सत्र चालु र अझै VPC मा कुनै रुट छैन यो तेस्रो अवस्था हो। ठेगाना बदल्नाले त्यहाँ फाइदा हुँदैन, किनभने सत्र पहिले नै चलिरहेको छ र प्रिफिक्स जाहेर हुँदैन वा प्राथमिकता पाउँदैन। यी तीन अवस्था छुट्ट्याउनु नै कामको ठूलो भाग हो।
प्रत्येक टनेललाई दुवै छेउ भरिएको आफ्नै /30 चाहिन्छ
प्रत्येक HA VPN टनेलले 169.254.0.0/16 बाट link-local /30 पाउँछ, एउटा ठेगाना Cloud Router इन्टरफेसमा र अर्को तपाईंको पियरमा। पियर फिल्डले टाढाको छेउ नाम दिनुपर्छ, कहिल्यै राउटरको आफ्नै ठेगाना होइन।
दुई टनेल भनेको Cloud Router मा दुई इन्टरफेस, प्रत्येक फरक /30 सहित। टनेल 0 को जोडी टनेल 1 मा फेरि प्रयोग गर्नु त्यो गल्ती हो जो सारांश तालिकामा सफा देखिन्छ र OPEN प्याकेटमा मर्छ।
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
जोडी कन्सोल सारांशबाट होइन, राउटर स्रोतबाट पढ्नुहोस्। सारांशले पियर ठेगाना गलत पढ्न सजिलो हुने स्तम्भमा देखाउँछ, र इन्टरफेसको ipRange तथा पियरको peerIpAddress ले एउटै /30 का विपरीत छेउ वर्णन गर्नुपर्छ।
अदलबदल प्रायः पुनर्निर्माणको क्रममा हुन्छ
टनेल पुनः निर्माण गर्दा नै जोडीहरू क्रस हुन्छन्। पुरानो टनेलको पियर ठेगाना नयाँ टनेलको इन्टरफेस फिल्डमा प्रतिलिपि हुन्छ, वा नयाँ सत्र अघिल्लो सत्रको पियरतर्फ मोडिन्छ। जसरी भए पनि Cloud Router ले OPEN प्याकेट अब आफैं भएको ठेगानामा वा पछाडि टनेल नभएको ठेगानामा पठाउँछ।
कन्सोल खोल्नुअघि जोडीहरू लेख्नुहोस्: टनेलको नाम, इन्टरफेस, राउटर ठेगाना, पियर ठेगाना, पियर ASN. त्यसपछि दुवै टनेल एकैचोटि बनाउनुहोस्, ताकि दोस्रो पहिलोको बाँकीले नभरियोस्।
सत्र पर्खनुका अरू तीन कारण
पहिलो पियर ASN हो: हरेक पक्ष अर्को पक्षको ASN सँग कन्फिगर हुनुपर्छ, र भिन्नता पियरसम्म पुग्छ तर कहिल्यै स्थापित हुँदैन। दोस्रो पियरको आफ्नै फायरवाल हो, जसले टनेल इन्टरफेसमा TCP 179 लाई अनुमति दिनुपर्छ; IKE वा ESP नियमले त्यो समेट्दैन। तेस्रो भनेको आफ्नो छिमेकीका रूपमा कन्फिगर गरिएको ठेगानाभन्दा फरक स्रोत ठेगानाबाट जवाफ दिने पियर हो।
पियरको आफ्नै लग निर्णायक हो। यसको BGP सारांशमा त्यो ठेगानाका लागि कुनै छिमेकी छैन भने प्याकेट आउँदैनन् र जोडी वा बाटो गलत छ। छिमेकी Active वा Connect मा छ भने प्याकेट आइरहेका छन् र सत्रका प्यारामिटर मिल्दैनन्।
प्याकेट जुन क्रममा यात्रा गर्छन् त्यही क्रममा जाँच्नुहोस्
बाहिरतर्फ काम गर्नुहोस्: टनेल स्थिति, त्यसपछि राउटरको BGP पियर स्थिति, त्यसपछि पियरको BGP सारांश, त्यसपछि रुटहरू। पहिलो दुई स्वस्थ छन् भने Cloud VPN पक्ष सम्पादन गर्न छोड्नुहोस् र पियर उपकरणमा काम गर्नुहोस्। राउटरले पियर बन्द भएको जनाए र तपाईंको उपकरणमा कुनै छिमेकी छैन भने जोडी गलत छ वा BGP पोर्ट फिल्टर भइरहेको छ। पियरको टनेल इन्टरफेसमा प्याकेट क्याप्चर गर्दा एकै नजरमा टुंगिन्छ, किनभने OPEN प्याकेट त्यहाँ या त पुग्छन् या कहिल्यै पुग्दैनन्।
gcloud compute routers get-status ROUTER --region=REGION ले पियर स्थिति यसले प्रयोग गरिरहेको ठेगानाको छेउमा छाप्छ, र त्यही नै तपाईंले तुलना गर्नुपर्ने जोडी हो।
सत्र स्थापित भएपछि सिकेको प्रिफिक्स VPC रुट तालिकामा देखिन्छ र दुवैतर्फ एकएक होस्टले जवाफ दिन्छ भन्ने पुष्टि गर्नुहोस्। त्यसपछि अन्तिम जोडीहरू टनेलका नामको छेउमा लेख्नुहोस्, ताकि अर्को पुनर्निर्माण कन्सोल सारांशबाट होइन, जाँचिएको तालिकाबाट सुरु होस्।