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 विज्ञापनमा संयोगवश देखिन्छ कि भन्नेमा भर पर्नुको सट्टा नीतिको सीमामा पहुँच सीमित गर्नुहोस्।

प्रत्येक रुट तालिका क्वेरीको अघि र पछिको अवस्था परिवर्तन अभिलेखमा सुरक्षित गर्नुहोस्। परिवर्तनले अवस्था बिगार्यो भने, अघिल्ला रुट पुनर्स्थापित गर्नुहोस् र उही क्वेरीले पुष्टि गर्नुहोस्, किनकि तपाईंले प्रमाणित गर्न नसक्ने रोलब्याक केवल एक अनुमान हो।