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 मध्ये शोधा आणि तिची वेळमुद्रा व संसाधन लेबल्स तपासा. चुकीच्या वेळमुद्रेचा दस्तऐवज गहाळ असलेल्यापेक्षा वाईट आहे, कारण तो जुना डेटा चालू दाखवतो.

रंगावर नाही, फरकावर इशारा द्या

दोन संकेत ठेवण्याचा मुद्दा संयोजनांमध्ये आहे. टनेल बंद असेल तर नेटवर्क मालकाला पेज करा; टनेल चालू आणि प्रोब अपयशी असेल तर ॲप मालकाला; प्रोबचा निकाल नसेल तर देखरेख एजंटच्या मालकाला. तिन्ही एका लाल पॅनेलमध्ये एकत्र केल्यास इशारा एका महिन्यात म्यूट होण्याची खात्री आहे. एका नमुन्यावर नाही, तर टिकाऊपणा विंडोसह सतत अपयशावर इशारा द्या, आणि अंतर्ग्रहण पाइपलाइनच्या स्वतःच्या आरोग्यासाठी वेगळी तपासणी जोडा.

कालच्या यशस्वी नमुन्यांनी भरलेला डॅशबोर्ड आज निरोगी मार्ग म्हणून वाचला जाऊ नये.

लिहिल्यावर करार छोटा आहे: टनेल मेट्रिक सांगते की गेटवेने वाटाघाटी केली, प्रोब सांगतो की वापरकर्ते जिथे बसतात तिथून मार्ग चालतो, आणि पाइपलाइन आरोग्य सांगते की दोन्हीपैकी कोणते उत्तर चालू आहे. डॅशबोर्डवरील बाकी सर्व भाष्य आहे.