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 में खोजें और उसका समय-चिह्न तथा संसाधन लेबल जाँचें। गलत समय-चिह्न वाला दस्तावेज़ गायब दस्तावेज़ से बुरा है, क्योंकि वह पुराने डेटा को वर्तमान जैसा दिखाता है।

अंतर पर चेतावनी दें, रंग पर नहीं

दो संकेत रखने का तर्क संयोजनों में है। टनल बंद हो तो नेटवर्क स्वामी को पेज करें; टनल चालू हो और जाँच विफल हो तो ऐप स्वामी को; जाँच का परिणाम गायब हो तो निगरानी एजेंट के स्वामी को। तीनों को एक लाल पैनल में डालने से चेतावनी एक महीने में म्यूट हो जाएगी। एकल नमूने पर नहीं, स्थायित्व विंडो के साथ लगातार विफलता पर चेतावनी दें, और अंतर्ग्रहण पाइपलाइन के स्वास्थ्य के लिए अलग जाँच जोड़ें।

कल के सफल नमूनों से भरा डैशबोर्ड आज स्वस्थ मार्ग नहीं पढ़ा जाना चाहिए।

लिखित रूप में अनुबंध छोटा है: टनल मीट्रिक बताती है कि गेटवे ने बातचीत की, जाँच बताती है कि रास्ता वहाँ से काम करता है जहाँ उपयोगकर्ता बैठते हैं, और पाइपलाइन स्वास्थ्य बताता है कि दोनों में से कोई जवाब वर्तमान है या नहीं। डैशबोर्ड पर बाकी सब टिप्पणी है।