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 जडान लग, वा क्लाइन्ट एपले देखाएको त्रुटि पाठ। मिल्ने क्लाइन्ट प्रयास नभएको गेटवे रेकर्डले क्लाइन्टतर्फ सङ्केत गर्छ; गेटवेले केही रेकर्ड नगर्दा क्लाइन्टले सफलता रिपोर्ट गरेमा सामान्यतया प्रोफाइल अर्को गेटवेतर्फ लक्षित छ भन्ने अर्थ हुन्छ।

दुवै आधा भाग एउटै टिकटमा राख्नुहोस्। एक्लै गेटवे लगले गलत निष्कर्षलाई निम्तो दिन्छ, र एक्लै क्लाइन्ट लगले प्याकेट कहिल्यै पुग्यो कि भन्ने देखाउन सक्दैन।

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

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

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

अन्तमा, सेटिङको नाम, कार्यक्षेत्र र छानिएका श्रेणीहरू गेटवेको रनबुकमा लेख्नुहोस्। अर्को व्यक्ति जसले क्लाइन्ट डिबग गर्नेछ, पहिले गेटवे ब्लेड हेर्नेछ, केही भेट्नेछैन, र लगहरू अवस्थित छैनन् भन्ने निष्कर्ष निकाल्नेछ।