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 मा खोज्नुहोस् र यसको समयछाप र स्रोत लेबल जाँच्नुहोस्। गलत समयछाप भएको कागजात हराएको भन्दा नराम्रो हुन्छ, किनकि यसले पुरानो डेटालाई हालको जस्तो देखाउँछ।

रङमा होइन, फरकमा सचेत गर्नुहोस्

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

हिजोका सफल नमुनाले भरिएको ड्यासबोर्ड आज स्वस्थ मार्गका रूपमा पढिनु हुँदैन।

लेख्दा सम्झौता सानो छ: टनेल मेट्रिकले गेटवेले वार्ता गरेको बताउँछ, प्रोबले मार्ग प्रयोगकर्ता बस्ने ठाउँबाट काम गर्छ भन्छ, र पाइपलाइन स्वास्थ्यले दुईमध्ये कुनै जवाफ हालको छ कि भन्छ। ड्यासबोर्डमा बाँकी सबै टिप्पणी हो।