શું તમારે જીવંત ટનલ પર 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 ની લોગ સક્ષમ કરવાની પ્રક્રિયા ટનલ દીઠ કાર્યપ્રવાહ અને તેની વિક્ષેપ ચેતવણીનું દસ્તાવેજીકરણ કરે છે, અને તેને ફેરફાર પછી નહીં પણ પહેલાં વાંચવા યોગ્ય છે. પછી ક્રમમાં ચકાસો: ટનલ પાછી આવી, રેકોર્ડ અપેક્ષિત પ્રવાહમાં દેખાઈ રહ્યા છે, અને રેકોર્ડ તમે જે પ્રશ્ન માટે ટિકિટ ખોલી તેનો જવાબ આપી રહ્યા છે. જો ત્રીજું નિષ્ફળ જાય, તો સમસ્યા પ્રવાહની પસંદગી હતી, લોગિંગ નહીં.