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 रूट तालिका में दिख रहा है और दोनों ओर एक-एक होस्ट जवाब दे रहा है। फिर अंतिम जोड़ियाँ टनल के नामों के बगल में दर्ज करें, ताकि अगला पुनर्निर्माण कंसोल सारांश की बजाय जाँची हुई तालिका से शुरू हो।