VGW के BGP विज्ञापन बनाम VPC रूट टेबल: क्या क्या बदलता है

VPC सबनेट रूट टेबल में गायब प्रीफ़िक्स और ग्राहक के राउटर पर गायब प्रीफ़िक्स दो अलग-अलग खराबियाँ हैं, और इनमें से केवल एक ही AWS रूट टेबल के अंदर ठीक होती है। वर्चुअल प्राइवेट गेटवे अपने VPC से जुड़े CIDR ब्लॉकों का विज्ञापन करता है; सबनेट रूट टेबल तय करती है कि कोई वर्कलोड अपना जवाब कहाँ भेजता है। दूसरे को पहले को बदलने का तरीका मानना इस निदान में सबसे आम गलत मोड़ है। नीचे दी गई जाँचें क्रम से चलाएँ और दोनों दिशाओं को अलग रखें।

कोई भी टेबल पढ़ने से पहले अटैचमेंट का नाम तय करें

साइट-से-साइट VPN या तो वर्चुअल प्राइवेट गेटवे पर समाप्त होता है या ट्रांज़िट गेटवे पर, और संसाधन ID तय करते हैं कि कौन-सा रूटिंग मॉडल लागू होता है। पहले उन्हें पढ़ें: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'। जवाब आपको बताता है कि आगे जाँची जाने वाली टेबल VPC रूट टेबल है या ट्रांज़िट गेटवे रूट टेबल।

अगर VPN ट्रांज़िट गेटवे से जुड़ा है, तो VPC रूट टेबल को कंट्रोल प्लेन मानना बंद करें। वहाँ VPC टेबल गेटवे अटैचमेंट की ओर इंगित करती है, और एसोसिएशन तथा प्रचार ट्रांज़िट गेटवे रूट टेबल में होते हैं। दोनों दृष्टिकोणों को मिलाने से गलत ऑब्जेक्ट के बारे में आत्मविश्वासी निष्कर्ष निकलते हैं।

AWS से ऑफ़िस की दिशा एक विज्ञापन है

VGW अटैचमेंट के लिए, गेटवे अपने VPC से जुड़े CIDR ब्लॉकों का BGP के ज़रिए ग्राहक गेटवे को विज्ञापन करता है। अलग सबनेट रूट जोड़ना, या किसी रूट को पीयर किए गए VPC या किसी उपकरण की ओर इंगित करना, कोई दूसरा जुड़ा CIDR नहीं जोड़ता और उस विज्ञापन में नहीं दिखता। अगर ऑफ़िस में प्रीफ़िक्स गायब है, तो कोई भी रूट टेबल संपादित करने से पहले प्राप्त रूटों की सूची की तुलना VPC एसोसिएशनों से करें।

सरल नियम के अपवाद हैं, इसलिए इसे इसके दायरे में रखें। VPN CloudHub व्यवस्था ग्राहक गेटवे के बीच साइट प्रीफ़िक्स का दोबारा विज्ञापन कर सकती है, और ट्रांज़िट गेटवे अपने प्रचार नियमों का पालन करता है। यह कथन कि VGW केवल अपने ही VPC का विज्ञापन करता है, एक उपयोगी डिफ़ॉल्ट है, ऐसा कानून नहीं जो आपके सामने आने वाली हर टोपोलॉजी को कवर करे।

ऑफ़िस से AWS की दिशा प्रचार और चयन है

विपरीत दिशा में VGW ऑफ़िस का प्रीफ़िक्स सीखता है, लेकिन अकेले यह किसी वर्कलोड को नहीं हिलाता। सबनेट रूट टेबल में या तो अटैचमेंट के लिए प्रचार सक्षम होना चाहिए या उसी गंतव्य के लिए स्थिर रूट होना चाहिए। जब एक ही प्रीफ़िक्स के लिए दोनों मौजूद हों, स्थिर रूट जीतता है, और सबसे लंबे प्रीफ़िक्स का मिलान दोनों से पहले चलता है।

अनुमान लगाने के बजाय मूल पढ़ें: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'। EnableVgwRoutePropagation मूल वाली प्रविष्टि BGP से आई है; CreateRoute मूल वाली प्रविष्टि किसी इंसान ने टाइप की है और तब तक जीतती रहेगी जब तक कोई उसे हटा न दे।

दोनों दिशाओं को अलग रखने वाली एक रनबुक

कुछ भी बदलने से पहले AWS की ओर चार तथ्य लिखें: अटैचमेंट का प्रकार, VPC के जुड़े CIDR, विचाराधीन प्रीफ़िक्स के लिए सबनेट रूट का मूल, और टनल तथा BGP की स्थिति। वही describe कॉल प्रत्येक टनल के लिए स्वीकृत रूटों की गिनती के साथ VgwTelemetry लौटाता है, जो बताता है कि AWS ने कोई रूट स्वीकार किए या नहीं। फिर इसकी तुलना उससे करें जो ग्राहक उपकरण ने वास्तव में इंस्टॉल किया। BGP में मौजूद पर फ़ॉरवर्डिंग टेबल में अनुपस्थित प्रीफ़िक्स स्थानीय आयात या सर्वोत्तम-मार्ग की समस्या है, AWS रूट टेबल की समस्या नहीं।

अगर सबनेट टेबल में प्रीफ़िक्स बिल्कुल नहीं है, तो प्रचार सक्षम करें या स्थिर रूट जोड़ें, फिर बदलाव को तत्काल मानने के बजाय प्रचार अंतराल के बाद वही क्वेरी दोबारा पढ़ें। अगर प्रीफ़िक्स मौजूद है और ट्रैफ़िक फिर भी विफल रहता है, तो कंट्रोल प्लेन को अकेला छोड़ें और डेटा पथ पर जाएँ।

वहाँ रहते हुए क्या न बदलें

एक गायब प्रीफ़िक्स ठीक करने के लिए असंबंधित रूट टेबलों पर प्रचार चालू या बंद न करें, और एक अनुपस्थित CIDR को ढकने के लिए डिफ़ॉल्ट रूट न जोड़ें। दोनों बदलाव प्रभाव का दायरा बढ़ाते हैं और अगला निदान कठिन बनाते हैं। संपादन को केवल उसी टेबल तक सीमित रखें जो विचाराधीन वर्कलोड सबनेट को सेवा देती है।

डेटा पथ इस सबसे अलग है। सुरक्षा समूह स्टेटफुल होते हैं, नेटवर्क ACL नहीं, और कोई होस्ट फ़ायरवॉल या असममित वापसी पथ उस ट्रैफ़िक को गिरा सकता है जिसे रूटिंग ने सही ढंग से पहुँचाया था। विज्ञापित एग्रीगेट भी अपने अंदर की हर सेवा को अधिकृत नहीं करता, इसलिए पहुँच को नीति की सीमा पर प्रतिबंधित करें, इस पर निर्भर होने के बजाय कि कोई पता संयोग से BGP विज्ञापन में दिखता है या नहीं।

प्रत्येक रूट टेबल क्वेरी का पहले और बाद का हिस्सा परिवर्तन रिकॉर्ड में सहेजें। अगर बदलाव चीज़ों को बदतर बनाता है, तो पिछले रूट बहाल करें और उसी क्वेरी से पुष्टि करें, क्योंकि जिस वापसी को आप सत्यापित नहीं कर सकते वह केवल एक अनुमान है।