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 कनेक्शन लॉग, या क्लाइंट ऐप द्वारा दिखाया गया त्रुटि पाठ। मेल खाते क्लाइंट प्रयास के बिना गेटवे रिकॉर्ड क्लाइंट की ओर इशारा करता है; जब गेटवे कुछ दर्ज नहीं करता और क्लाइंट सफलता बताता है, तो आमतौर पर इसका अर्थ है कि प्रोफ़ाइल किसी दूसरे गेटवे की ओर है।

दोनों आधे हिस्सों को एक ही टिकट में रखें। अकेला गेटवे लॉग गलत निष्कर्ष को आमंत्रित करता है, और अकेला क्लाइंट लॉग यह नहीं दिखा सकता कि पैकेट कभी पहुँचा या नहीं।

यदि कहीं कुछ नहीं दिखता, तो प्लेटफ़ॉर्म पर संदेह करने से पहले क्लाइंट की घड़ी जाँचें। तिरछे टाइमस्टैम्प सहसंबंध को इस तरह विफल कर देते हैं कि वह बिल्कुल गायब डेटा जैसा दिखता है।

अवधारण, दायरा और रनबुक प्रविष्टि

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

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