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 रूट तक्त्यात दिसतो आणि दोन्ही बाजूंना एक एक होस्ट उत्तर देतो याची खात्री करा. नंतर अंतिम जोड्या टनेलच्या नावांशेजारी नोंदवा, जेणेकरून पुढील पुनर्बांधणी कन्सोल सारांशाऐवजी तपासलेल्या तक्त्यापासून सुरू होईल.