Azure Site VPN મોનિટરિંગ: ટનલ સ્થિતિને વાસ્તવિક પ્રોબ સાથે જોડો

દરેક ડેશબોર્ડ લીલું છે, ટનલ અગિયાર દિવસથી ચાલુ છે, અને શાખા આંતરિક એપ લોડ કરી શકતી નથી. આ લક્ષણ માટે જ આ ડિઝાઇન છે, અને તે મોનિટરિંગ ખામી નથી. ટનલની સ્થિતિ વાટાઘાટ વિશેના પ્રશ્નનો જવાબ આપે છે, જ્યારે વપરાશકર્તા ચાર રૂટિંગ નિર્ણયો અને એક નીતિ સ્તરમાંથી પસાર થતી વિનંતિ વિશે પૂછે છે. બંને સંકેત જોઈએ, અલગ રાખીને, અને રાત્રે તેમને અલગ પાડવાનો રસ્તો.

ટનલથી નહીં, નિષ્ફળ લક્ષણથી શરૂ કરો

સ્થાપિત સુરક્ષા સંગઠન એટલે બંને પક્ષોએ પ્રસ્તાવ પર સંમતિ આપી અને કી સ્થાપિત કરી. તેનો અર્થ એ નથી કે સિલેક્ટર વપરાશકર્તાને જોઈતું સબનેટ આવરી લે છે, દૂરના પક્ષ પાસે પરત માર્ગ છે, અથવા ફાયરવોલ ડિક્રિપ્શન પછી પોર્ટ સ્વીકારે છે. ટ્રાફિક ટનલની શાખા બાજુ પર પણ નિષ્ફળ જઈ શકે છે, અને પછી Azure કંઈ જ જોતું નથી અને સંપૂર્ણ સ્વાસ્થ્ય જાહેર કરે છે. ટનલ મેટ્રિક જરૂરી છે અને ક્યારેય પૂરતું નથી.

ત્રણ સ્થિતિઓ અલગ પડવી જોઈએ: ટનલ બંધ છે, ટનલ ચાલુ છે અને સેવા નિષ્ફળ છે, અને મોનિટરિંગ સ્રોત પોતે ઉપલબ્ધ નથી.

પ્રોબને ત્યાં મૂકો જ્યાં વપરાશકર્તાઓ છે

શાખાથી Azure એપ માટે, શાખાના વર્કલોડ નેટવર્કના હોસ્ટ પરથી સિન્થેટિક પરીક્ષણ ચલાવો અને તેને ખાનગી HTTPS પ્રવેશ બિંદુ તરફ નિર્દેશ કરો જ્યાં વપરાશકર્તાઓ ખરેખર પહોંચે છે. ગેટવેથી શરૂ કરાયેલ પ્રોબ અલગ સ્રોત સરનામું અને ઘણી વાર અલગ નીતિ માર્ગ વાપરે છે, તેથી દરેક વપરાશકર્તા નિષ્ફળ થાય ત્યારે પણ તે પસાર થઈ શકે છે. Azure Connection Monitor પરીક્ષણ જૂથો અને થ્રેશોલ્ડ સાથે TCP, ICMP અને HTTP તપાસને સમર્થન આપે છે, અને તેના સ્થાનિક સ્રોતોની એજન્ટ જરૂરિયાતો Azure બાજુની જરૂરિયાતોથી અલગ છે. બ્લોગમાંથી નિવૃત્ત થયેલી ક્લાસિક મોનિટર રેસિપી કોપી કરવાને બદલે હાલમાં સમર્થિત ગોઠવણ તપાસો.

પ્રોબને સાંકડી અને કંટાળાજનક રાખો: એક ગંતવ્ય, એક પોર્ટ, ઓપરેટિંગ જરૂરિયાત સાથે મેળ ખાતી આવૃત્તિ, અને તે સ્રોત માટે સ્પષ્ટ મંજૂરી નિયમ.

સેવા સાથે મેળ ખાતી તપાસ પસંદ કરો

સેવા પોર્ટ પર TCP જોડાણ ટનલ દ્વારા પરિવહન પહોંચ દર્શાવે છે અને TLS કે એપ વિશે કંઈ કહેતું નથી. HTTP તપાસ સ્થિતિની અપેક્ષા ઉમેરે છે અને એવા શ્રોતાને પકડે છે જે જોડાણ સ્વીકારે છે પણ સેવા આપી શકતું નથી, જે પ્રમાણપત્ર કે બેકએન્ડ ફેરફાર પછી વધુ સામાન્ય નિષ્ફળતા છે. પરીક્ષણ ખરેખર પ્રમાણીકરણ ન કરે તો બંનેમાંથી કોઈ પ્રમાણીકૃત વ્યવસાયિક વ્યવહાર નથી, તેથી ડેશબોર્ડ પર તેને તે રીતે લેબલ ન કરો. વપરાશકર્તાની ફરિયાદ થાય ત્યારે જે તપાસ નિષ્ફળ થાય તે પસંદ કરો.

ICMP ત્રણમાં સૌથી નબળો વિકલ્પ છે, કારણ કે ઘણા સ્ટેક નીતિ અનુસાર તેને છોડી દે છે અને નિષ્ફળ પિંગ બહુ ઓછું સાબિત કરે છે.

બંને સંકેતને બનાવ્યા વિના Elastic માં લાવો

VPN ગેટવે ટનલના આઉટગોઇંગ અને ઇનગોઇંગ બાઇટ્સ અને પેકેટ ડ્રોપ કાઉન્ટર જેવા પ્લેટફોર્મ મેટ્રિક્સ બહાર કાઢે છે, અને ટનલ તથા IKE ઘટનાઓ સહિતની શ્રેણીઓમાં ડાયગ્નોસ્ટિક લોગ મોકલી શકે છે. Connection Monitor પરિણામો Azure Monitor દ્વારા મેટ્રિક્સ તરીકે અને Log Analytics વર્કસ્પેસ દ્વારા લોગ રેકોર્ડ તરીકે આવે છે. તેમાંથી કંઈ પણ જાતે Elastic ઇન્ડેક્સમાં દેખાતું નથી. મેટ્રિક્સ માટે એક સમર્થિત પાઇપલાઇન અને લોગ માટે બીજી પસંદ કરો, સામાન્ય રીતે Azure Event Hub ઇનપુટ અથવા Azure Monitor એકીકરણ, અને ઇન્ડેક્સ પેટર્ન પર ભરોસો કરતા પહેલા સ્થાપિત એકીકરણ ખરેખર શું લે છે તે ચકાસો.

એ લેબલ રાખો જે ઓપરેટરને બે ડેટાસેટ જોડવા દે છે: પ્રોબ માટે સ્રોત એન્ડપોઇન્ટ, ગંતવ્ય, પ્રોટોકોલ અને પોર્ટ, અને ગેટવે માટે ટનલ ઓળખ તથા પીઅર સરનામું.

એક નિયંત્રિત ઘટના સાથે પાઇપલાઇન માન્ય કરો, પછી તેને Elastic માં શોધો અને તેની સમયમુદ્રા અને સ્રોત લેબલ તપાસો. ખોટી સમયમુદ્રાવાળું દસ્તાવેજ ગુમ થયેલા કરતાં ખરાબ છે, કારણ કે તે જૂનો ડેટા વર્તમાન જેવો દેખાડે છે.

રંગ પર નહીં, તફાવત પર ચેતવણી આપો

બે સંકેત રાખવાનો મુદ્દો સંયોજનોમાં છે. ટનલ બંધ હોય તો નેટવર્ક માલિકને પેજ કરો; ટનલ ચાલુ હોય અને પ્રોબ નિષ્ફળ જાય તો એપ માલિકને; પ્રોબ પરિણામ ગુમ હોય તો મોનિટરિંગ એજન્ટનો માલિક જે હોય તેને. ત્રણેયને એક લાલ પેનલમાં ભેગા કરવાથી ચેતવણી એક મહિનામાં મ્યૂટ થવાની ખાતરી છે. એક નમૂના પર નહીં, સ્થિરતા વિન્ડો સાથે ટકાઉ નિષ્ફળતા પર ચેતવણી આપો, અને ઇન્જેશન પાઇપલાઇનની પોતાની સ્વાસ્થ્ય માટે અલગ તપાસ ઉમેરો.

ગઈકાલના સફળ નમૂનાથી ભરેલું ડેશબોર્ડ આજે સ્વસ્થ માર્ગ તરીકે વંચાવું જોઈએ નહીં.

લખિતમાં કરાર નાનો છે: ટનલ મેટ્રિક કહે છે કે ગેટવેએ વાટાઘાટ કરી, પ્રોબ કહે છે કે વપરાશકર્તા જ્યાં બેસે છે ત્યાંથી માર્ગ કામ કરે છે, અને પાઇપલાઇન સ્વાસ્થ્ય કહે છે કે બેમાંથી કોઈ જવાબ વર્તમાન છે કે નહીં. ડેશબોર્ડ પર બાકીનું બધું ટીકા છે.