लाइभ टनेलमा AWS VPN टनेल लगहरू सक्षम गर्नुपर्छ?

Site-to-Site VPN का लागि टनेल गतिविधि लगहरू खोल्नु सानो परिवर्तन हो जसले यसले नापिरहेको टनेललाई खसाल्न सक्छ। AWS चेतावनी दिन्छ कि विद्यमान टनेलमा लगिङ सक्षम गर्दा त्यो केही मिनेटका लागि अवरुद्ध हुन सक्छ, त्यसैले रोचक प्रश्न झन्डा कसरी पल्टाउने भन्ने होइन, तर कुन टनेलमा र कहिले पल्टाउने भन्ने हो। तीन सर्तले क्रम निर्धारण गर्छन्: अर्को टनेलले साँच्चै मार्गहरू बोक्छ कि बोक्दैन, तपाईंलाई सेवा घटनाहरू चाहिन्छ कि BGP घटनाहरू, र परिवर्तन कन्सोलबाट जान्छ कि टनेल विकल्प API बाट। यीमा गल्ती गरे तपाईंसँग या त अवरोध हुन्छ या केही पनि नभएको लग समूह।

तीन सर्तले क्रम निर्धारण गर्छन्

तपाईं परिवर्तन गरिरहेको वस्तुको पहिचानबाट सुरु गर्नुहोस्। तपाईंलाई VPN जडान ID, क्षेत्र र त्यो विशेष टनेलको बाह्य IP ठेगाना चाहिन्छ, किनकि यस सुविधाको प्रत्येक लग सेटिङ जडान अनुसार होइन, टनेल अनुसार हुन्छ। गलत बाह्य ठेगानामा लागू गरिएको परिवर्तन त्यो टनेलमा गरिएको परिवर्तन हो जसलाई कसैले डिबग गरिरहेको थिएन।

गन्तव्य उही क्षेत्रको CloudWatch लग समूह हो, तपाईंले साँच्चै चाहेको रिटेन्सन र पहुँच नीतिसहित। साधारण नामहरूले भेट्न सक्ने स्रोत-नीति आकार सीमाहरू यसले टार्छ भनेर AWS यी समूहहरूका लागि /aws/vendedlogs/ उपसर्ग सिफारिस गर्छ। /aws/vendedlogs/vpn/branch-a-activity जस्तो नाम केवल उदाहरण हो; महत्त्वपूर्ण कुरा समूह अवस्थित हुनु, डेलिभरी भूमिकाले त्यसमा लेख्न सक्नु, र दुवैलाई VPN कन्फिगरेसनको मालिकले व्यवस्थापन गर्नु हो। नामले अनुमति दिँदैन, र डेलिभरी नीतिबिना बनाइएको समूहले त्रुटिको सट्टा मौनता उत्पन्न गर्छ।

पहिलो सर्त: साँच्चै ट्राफिक बोक्ने अतिरिक्त टनेल

यो त्यो सर्त हो जुन टोलीहरूले छोड्छन्। दुई कन्फिगर गरिएका टनेलहरू अनुप्रयोगसँग प्रयोगयोग्य वैकल्पिक मार्ग छ भन्ने प्रमाण होइनन्।

एउटा टनेल छुनु अघि, अर्कोले महत्त्वपूर्ण मार्गहरू बोकिरहेको छ भनी पुष्टि गर्नुहोस्: ग्राहक गेटवे पट्टिको राउटिङ तालिका जाँच्नुहोस् र अनुप्रयोगले साँच्चै फेलओभर गर्न सक्छ भनी पुष्टि गर्नुहोस्। AWS को अवरोध विन्डो मिनेटमा हुन्छ, सेकेन्डमा होइन, र केवल कागजमा रहेको टनेलले निदान परिवर्तनलाई अवरोधमा बदल्छ। यदि अतिरिक्त मार्ग प्रमाणित छैन भने, लगिङलाई निष्क्रिय मान्नुको सट्टा अन्य कुनै पनि राउटिङ परिवर्तनजत्तिकै सावधानीसाथ परिवर्तनको योजना बनाउनुहोस्। जसको व्यवहार तपाईं व्याख्या गर्न खोज्दै हुनुहुन्छ त्यही टनेलमा उपकरण जडान गर्नुहोस्, पुग्न सजिलो हुनेमा होइन।

दोस्रो सर्त: गतिविधि लग कि BGP लग

यसले तपाईंले साँच्चै के पढ्न सक्नुहुनेछ भन्ने निर्धारण गर्छ। गतिविधि अभिलेखहरूले IKE र IPsec स्थिति संक्रमण र DPD सन्देशहरूजस्ता सेवा घटनाहरू समेट्छन्, जुन टनेल माथि नआउँदा वा लगातार कुञ्जी नवीकरण गर्दा तपाईंलाई चाहिने कुरा हो। BGP अभिलेखहरू आफ्नै नियन्त्रणसहितको छुट्टै प्रवाह हुन्, र तिनीहरू फरक प्रश्नको उत्तर दिन्छन्: मार्गहरू अपेक्षाअनुसार साटासाट र फिर्ता भए कि भएनन्।

गतिविधि झन्डा सक्षम गर्नु सेवाले निकाल्न सक्ने प्रत्येक प्रवाहका लागि अनुरोध होइन। शंका राउटिङमा छ भने दुवै सक्षम गर्नुहोस्; शंका चरण 1 वा चरण 2 वार्तामा छ भने गतिविधि प्रवाहले नै त्यो देखाउँछ।

दुवैमध्ये कुनै पनि प्रवाह प्याकेट क्याप्चर होइन, र यो भिन्नताले आवश्यकताभन्दा बढी टिकट समाधान गर्छ। गतिविधि र BGP अभिलेखहरूले सेवाले टनेल र सत्रसँग के गर्यो भन्ने बताउँछन्, तपाईंको अनुप्रयोगले त्यसबाट के पठायो भन्ने होइन। अनुप्रयोगको समय-समाप्ति डिबग गर्न टनेल लगतिर हात बढाउनु श्रेणीको त्रुटि हो, र कसैले याद गर्नु अघि यसले सामान्यतया एउटा अवरोध विन्डोको मूल्य तिराउँछ। पहिले प्रश्न छान्नुहोस्, त्यसपछि त्यसको उत्तर दिन सक्ने प्रवाह।

तेस्रो सर्त: कन्सोल परिवर्तन कि टनेल विकल्प API

यदि मानिसले एक पटकको परिवर्तन गर्दैछ भने कन्सोल मार्ग ठीक छ: VPC console, Site-to-Site VPN connections, जडान छान्नुहोस्, Actions, Modify VPN tunnel options, बाह्य IP छान्नुहोस्, Tunnel activity log सक्षम गर्नुहोस्, समूह र आउटपुट ढाँचा छान्नुहोस्, विन्डोभित्र सुरक्षित गर्नुहोस्। यदि VPN कोडका रूपमा व्यवस्थापन गरिन्छ भने त्यही क्लिक पछि मिलाउनुपर्ने ड्रिफ्ट हो।

स्वचालनका लागि, टनेल विकल्पहरूको गतिविधि-लग भागको निश्चित आकार छ: LogOptions जसमा CloudWatchLogOptions छ, साथै LogEnabled, LogGroupArn र LogOutputFormat। त्यो ब्लक टुक्रा हो, अनुरोध होइन; modify-vpn-tunnel-options लाई अझै जडान ID र टनेलको बाह्य IP चाहिन्छ, र बाँकी टनेल सेटिङहरू टेम्प्लेटको मालिकले जोगाउनुपर्छ। BGP लगिङले त्यही संरचनामा आफ्नै BgpLogEnabled, BgpLogGroupArn र BgpLogOutputFormat कुञ्जीहरू प्रयोग गर्छ। कल लागू भयो भन्ने विश्वास गर्नुको सट्टा describe-vpn-connections ले परिवर्तन फेरि पढ्नुहोस्।

अभिलेखहरूले तपाईंलाई के भन्न सक्छन् र के सक्दैनन्

पहिलो टनेल सकिएपछि र इच्छित मार्ग उपलब्ध भएपछि, दोस्रो टनेलको लग पनि चाहिन्छ भने त्यही नियन्त्रित क्रम दोहोर्याउनुहोस्। एक पटकमा एउटा टनेल भन्ने नै पूरा कुरा हो।

अभिलेखहरू जडान र टनेलको बाह्य ठेगानाद्वारा पहिचान गरिएका प्रवाहहरूमा आउँछन्, त्यसैले इतिहास पछाडिबाट देखिन्छ भन्ने अपेक्षा गर्नुको सट्टा त्यो पहिचानसँग सहसम्बन्ध राख्नुहोस्। परिवर्तन अघि केही पनि अवस्थित छैन, र कति पर्खे पनि त्यो खाली ठाउँ भरिँदैन। तपाईंलाई आधाररेखा चाहिएमा तुलना गर्न केही हुन् भनेर परिवर्तन अघि हालको टनेल अवस्था र राउटिङ तालिका कैद गर्नुहोस्।

लग समूह, त्यसको रिटेन्सन, डेलिभरी अनुमतिहरू र टनेल विकल्प ब्लकलाई VPN सँगै एउटै सूचीमा राख्नुहोस्, किनकि ती चार ठाउँमा फैलिएको एउटै कन्फिगरेसन हुन्। AWS को लग सक्षम गर्ने प्रक्रिया ले प्रत्येक टनेलको कार्यप्रवाह र त्यसको अवरोध चेतावनी अभिलेख गर्छ, र यो परिवर्तनपछि होइन, अघि पढ्न योग्य छ। त्यसपछि क्रममा जाँच्नुहोस्: टनेल फर्कियो, अभिलेखहरू अपेक्षित प्रवाहमा देखिइरहेका छन्, र अभिलेखहरूले तपाईंले टिकट खोलेको प्रश्नको उत्तर दिइरहेका छन्। तेस्रो असफल भएमा समस्या लगिङमा होइन, प्रवाहको छनोटमा थियो।