लाइव्ह टनेलवर 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 ची लॉग सक्षम करण्याची प्रक्रिया प्रत्येक टनेलचा कार्यप्रवाह आणि त्याची व्यत्यय चेतावणी नोंदवते, आणि ती बदलानंतर नाही तर आधी वाचण्यासारखी आहे। मग क्रमाने पडताळा: टनेल परत आले, नोंदी अपेक्षित प्रवाहात दिसत आहेत, आणि नोंदी तुम्ही तिकीट उघडलेल्या प्रश्नाचे उत्तर देत आहेत। तिसरे अयशस्वी झाल्यास समस्या लॉगिंगमध्ये नाही तर प्रवाहाच्या निवडीत होती।