क्या आपको लाइव टनल पर 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 की लॉग सक्षम करने की प्रक्रिया प्रति-टनल कार्यप्रवाह और उसकी रुकावट चेतावनी का दस्तावेजीकरण करती है, और इसे बदलाव के बाद नहीं बल्कि पहले पढ़ना उचित है। फिर क्रम में सत्यापित करें: टनल वापस आई, रिकॉर्ड अपेक्षित धारा में दिख रहे हैं, और रिकॉर्ड उस सवाल का जवाब दे रहे हैं जिसके लिए आपने टिकट खोला था। यदि तीसरा विफल हो, तो समस्या धारा का चयन थी, लॉगिंग नहीं।