തത്സമയ ടണലിൽ 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-ന്റെ ലോഗുകൾ പ്രവർത്തനക്ഷമമാക്കാനുള്ള നടപടിക്രമം ഓരോ ടണലിന്റെയും വർക്ക് ഫ്ലോയും അതിന്റെ തടസ്സ മുന്നറിയിപ്പും രേഖപ്പെടുത്തുന്നു, മാറ്റത്തിന് ശേഷമല്ല, മുമ്പ് അത് വായിക്കുന്നത് മൂല്യവത്താണ്. തുടർന്ന് ക്രമമായി പരിശോധിക്കുക: ടണൽ തിരികെ വന്നു, റെക്കോർഡുകൾ പ്രതീക്ഷിച്ച സ്ട്രീമിൽ പ്രത്യക്ഷപ്പെടുന്നു, ആ റെക്കോർഡുകൾ നിങ്ങൾ ടിക്കറ്റ് തുറന്ന ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. മൂന്നാമത്തേത് പരാജയപ്പെട്ടാൽ, പ്രശ്നം ലോഗിംഗല്ല, സ്ട്രീം തിരഞ്ഞെടുപ്പായിരുന്നു.