Azure Point-to-Site VPN चे लॉग कुठे आहेत? Monitor मध्ये पहा

वापरकर्ता Point-to-Site गेटवेला कनेक्ट होऊ शकत नाही, तुम्ही गेटवे ब्लेड उघडता, आणि पानावर कुठेही कनेक्शन इतिहास नाही। कॉन्फिगरेशन, प्रमाणपत्रे, स्थिती: सर्व आहे, रेकॉर्ड नाहीत। लॉग अस्तित्वात आहेत, परंतु नेटवर्किंग पाने ते अजिबात तयार करत नाहीत। ते गेटवे संसाधनाशी जोडलेल्या डायग्नोस्टिक सेटिंगमधून येतात, आणि ती सेटिंग Monitor अंतर्गत राहते; म्हणून स्पष्ट जागी पहिला शोध काहीही परत देत नाही, आणि लोक असा निष्कर्ष काढतात की सेवा कोणताही ऑडिट ट्रेल ठेवत नाही।

स्पष्ट शोध का अयशस्वी होतो

जुन्या मार्गदर्शकांमध्ये असे म्हटले आहे की Azure Point-to-Site VPN मध्ये ऑडिट नाही, आणि सेवा प्रति-कनेक्शन कोणताही रेकॉर्ड उघड करत नव्हती तेव्हा हे खरे होते। सध्याचे गेटवे टनेल डायग्नोस्टिक रेकॉर्ड प्रकाशित करतात, म्हणून उपयुक्त प्रश्न बदलला आहे: लॉग आहेत की नाही हे नाही, तर कोणते संसाधन ते उत्सर्जित करते आणि तुम्ही कोणती श्रेणी सुरू केली। गेटवे ब्लेड ही कॉन्फिगरेशन पृष्ठभाग आहे, आणि कॉन्फिगरेशन पृष्ठभाग क्वचितच लॉग व्ह्यूअर म्हणूनही काम करतात। डायग्नोस्टिक सेटिंग प्रति-संसाधन वस्तू आहे, म्हणून तुम्ही निवडलेले संसाधन पुढील सर्व गोष्टी ठरवते।

गोंधळाचा दुसरा अर्धा भाग प्रमाणीकरण आहे। प्रमाणपत्र-आधारित Point-to-Site कनेक्शन ओळख प्रदात्याप्रमाणे प्रति-वापरकर्ता साइन-इन इव्हेंट तयार करत नाहीत, म्हणून पासवर्ड टाइप करणाऱ्या नामांकित व्यक्तीचा रेकॉर्ड सापडत नाही।

डायग्नोस्टिक सेटिंग गेटवे संसाधनाशी जोडा

Monitor उघडा, नंतर Diagnostic settings, आणि नवीन सेटिंग जोडा जिचे लक्ष्य व्हर्च्युअल नेटवर्क गेटवे स्वतः आहे, ते असलेले व्हर्च्युअल नेटवर्क नाही। Point-to-Site डायग्नोस्टिक श्रेणी निवडा, जिचे नाव P2SDiagnosticLog आहे, कारण तीच प्रति-क्लायंट कनेक्शन रेकॉर्ड धारण करते; टनेल, रूट किंवा IKE श्रेणी केवळ त्या कव्हर करणाऱ्या site-to-site त्रुटींसाठी जोडा। नंतर डेटा तुम्ही नियंत्रित करता त्या Log Analytics कार्यक्षेत्रात पाठवा, तुम्ही जाणीवपूर्वक निवडलेल्या धारण कालावधीसह। बहुतेक अयशस्वी शोध चुकीच्या संसाधनाशी जोडलेली सेटिंग असतात, गहाळ वैशिष्ट्य नाही।

श्रेणी सूची गेटवे प्रकार आणि पिढीनुसार भिन्न असतात। Point-to-Site श्रेणी नसल्यास, गेटवे या वैशिष्ट्यापेक्षा जुने असू शकते किंवा अशा SKU वर चालू शकते जे ते कधीही उत्सर्जित करत नाही, म्हणून परवानगी समस्या शोधण्यापूर्वी समर्थित श्रेणी तपासा। Point-to-Site श्रेणी नसलेले गेटवे खराब नाही; ते फक्त त्या रेकॉर्डचा स्रोत होऊ शकत नाही, आणि सर्वात जवळचा पर्याय टनेल किंवा IKE श्रेणी आहे, जी Point-to-Site सत्राचे वर्णन करत नसली तरी क्लायंटचा पत्ता नोंदवते। गहाळ लॉगबद्दल समर्थन केस उघडण्यापूर्वी श्रेणी सूचीची पुष्टी करा।

तुमचा मोड ज्या तक्त्याचा वापर करतो त्यात रेकॉर्ड वाचा

जुन्या संग्रह मोडमध्ये, नोंदी AzureDiagnostics तक्त्यात जातात आणि श्रेणी स्तंभ मूल्य म्हणून दिसते; संसाधन-विशिष्ट तक्त्यांमध्ये गेटवेचा स्वतःचा तक्ता असतो। कोणत्याही परिस्थितीत, गेटवे संसाधन आणि अयशस्वी प्रयत्नाभोवतीच्या वेळेच्या खिडकीने क्वेरी करा, आणि नंतर वैयक्तिक पंक्तींऐवजी सहसंबंध वाचा:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

स्तंभ संच तुमच्या संग्रह मोडचे अनुसरण करतो, म्हणून क्वेरीला स्क्रिप्ट नाही, आकार माना। तुम्ही शोधत असलेला क्लायंट पत्ता दिसतो आणि नंतर अदृश्य होतो, अशा निकाल प्रकारासह जो यश नाही।

गेटवे रेकॉर्ड क्लायंटच्या स्वतःच्या दृष्टिकोनाशी जुळवा

गेटवे लॉग टनेलचे वर्णन करतात, लॅपटॉप ते का तयार करू शकला नाही हे नाही। त्याच टाइमस्टॅम्पवर क्लायंट बाजू गोळा करा: RAS क्लायंटसाठी Windows इव्हेंट लॉग, macOS कनेक्शन लॉग, किंवा क्लायंट अ‍ॅपने दाखवलेला त्रुटी मजकूर। जुळणारा क्लायंट प्रयत्न नसलेला गेटवे रेकॉर्ड क्लायंटकडे निर्देश करतो; गेटवे काहीही नोंदवत नसताना क्लायंट यश नोंदवत असेल तर सामान्यतः प्रोफाइल दुसऱ्या गेटवेकडे लक्ष्यित आहे असा अर्थ होतो।

दोन्ही अर्धे भाग एकाच तिकिटात ठेवा। एकटा गेटवे लॉग चुकीच्या निष्कर्षाला आमंत्रण देतो, आणि एकटा क्लायंट लॉग पॅकेट कधी पोहोचले का हे दाखवू शकत नाही।

दोन्ही ठिकाणी काहीही दिसत नसल्यास, प्लॅटफॉर्मवर शंका घेण्यापूर्वी क्लायंटचे घड्याळ तपासा। तिरपे टाइमस्टॅम्प सहसंबंध अशा प्रकारे अयशस्वी करतात की ते अगदी गहाळ डेटासारखे दिसते।

धारण, व्याप्ती आणि रनबुक नोंद

टनेल रेकॉर्ड क्लायंट पत्ते आणि कनेक्शन टाइमस्टॅम्प धारण करतात, म्हणून प्लॅटफॉर्मचे डीफॉल्ट सोडण्याऐवजी त्यांना विलोपन वेळापत्रकासह वैयक्तिक डेटा माना। कार्यक्षेत्र सदस्यतातील प्रत्येक संसाधनाची प्रत्येक श्रेणी घेत नाही याचीही खात्री करा, कारण गोंगाटाचे कार्यक्षेत्र सहसंबंध क्लायंट लॉग थेट वाचण्यापेक्षा मंद करते।

शेवटी, सेटिंगचे नाव, कार्यक्षेत्र आणि निवडलेल्या श्रेणी गेटवेच्या रनबुकमध्ये लिहा। पुढील व्यक्ती जो क्लायंट डीबग करेल तो प्रथम गेटवे ब्लेड पाहील, काहीही सापडणार नाही, आणि लॉग अस्तित्वात नाहीत असा निष्कर्ष काढेल।