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

क्रम सूचीभन्दा बढी महत्त्वपूर्ण छ।

जाँच 1: टनेलले के बोक्नुपर्ने हो ठेगान गर्नुहोस्

Azure VPN Gateway ले टनेल अन्त्य गरी VNet सँग सम्बन्धित ट्राफिक अगाडि पठाउँछ; योसामान्य इन्टरनेट निकास होइन. प्रयोगकर्ताहरूले आफ्नो ब्राउजिङ Azure बाट बाहिर जानेपर्छ भन्ने अपेक्षा गर्छन् भने कुनै पनि क्लाइन्ट सेटिङ आउनुअघि नै डिजाइन गलत छ। split tunneling सक्रिय गर्नुहोस् ताकि स्थानीय इन्टरनेट स्थानीय मार्गमै रहोस्, र स्थिर निकास ठेगाना साँच्चै आवश्यक हुँदा NAT इन्स्टेन्स वा साइट-टु-साइट टनेल प्रयोग गर्नुहोस्।

केही परीक्षण गर्नुअघि क्लाइन्ट कहाँ पुग्नुपर्ने हो लेख्नुहोस्। त्यो सूची बिना हरेक आंशिक नतिजा प्रगति जस्तो देखिन्छ।

जाँच 2: प्रमाणपत्रअघि ठेगाना ठाउँहरू तुलना गर्नुहोस्

ओभरल्याप फराकिला दायराहरूमा निर्क्योल गरिन्छ, त्यसैले सबनेट तहमा फरक देखिने दुई सञ्जाल पनि तिनका मूल ब्लक ओभरल्याप भए सङ्घर्ष गर्छन्। गेटवे सबनेट समर्पित र SKU का लागि पर्याप्त ठूलो हुनुपर्छ, र क्लाइन्ट ठेगाना पूल VNet वा peering मार्फत पुग्ने कुनै पनि कुरासँग सङ्घर्ष गर्नु हुँदैन। योजना बदलेर पुनः तैनाथ गर्नुहोस्, किनभने क्षतिपूर्तिका लागि मार्ग थप्दा केही गन्तव्यमा काम गर्ने र अरूमा अव्याख्यायोग्य रूपमा नगर्ने टनेल बन्छ। यहाँ प्रोभिजनिङ ठूलो स्वरमा असफल हुन्छ, र त्यही राम्रो अवस्था हो।

प्रमाणीकरण अर्को ढोका हो। प्रमाणपत्र, RADIUS र Entra ID प्रोफाइल आपसमा साट्न मिल्दैन, र प्रत्येकका लागि क्लाइन्ट प्याकेज फरक छ।

जाँच 3: भित्रबाट निजी नाम समाधान गर्नुहोस्

क्लाइन्टले आफ्नै रिजोल्भर राख्छ, जबसम्म डाउनलोड गरिएको प्रोफाइलमा VNet का DNS सर्भर हुँदैनन्, र त्यो सूची डाउनलोडको समयमै जोडिन्छ। VNet भित्र forwarder थप्नुहोस्, त्यसलाई VNet को DNS सर्भर बनाउनुहोस्, त्यसपछि क्लाइन्ट प्याकेज फेरि डाउनलोड गरी आयात गर्नुहोस्। पुरानो प्याकेज पुनः प्रयोग गर्दा पुरानो रिजोल्भर सूची मात्र परीक्षण हुन्छ।

पहिले ठेगाना परीक्षण गर्नुहोस्, किनभने यसले एकै चरणमा राउटिङ र नामकरण अलग गर्छ: Test-NetConnection 10.20.1.4 -Port 3389।

ठेगानाले जवाफ दिएर नामले नदिए, रिजोल्भरलाई सिधै सोध्नुहोस् Resolve-DnsName files.corp.example -Server 10.20.0.4। दुवै असफल भए, दोष DNS को होइन र तपाईंले DNS सेटिङ सम्पादन गर्न छोड्नुपर्छ। 168.63.129.16 मा Azure प्लेटफर्म DNS ले VNet भित्रबाट मात्र जवाफ दिन्छ, त्यसैले बाहिरको क्लाइन्टले त्यो ठेगाना रिजोल्भरका रूपमा प्रयोग गर्न सक्दैन।

जाँच 4: टनेलपछाडिको सेवा परीक्षण गर्नुहोस्

स्वस्थ टनेल र बन्द पोर्ट क्लाइन्टको तर्फबाट एउटै देखिन्छन्। अतिथि फायरवाल, त्यसपछि सबनेट वा NIC मा नेटवर्क सुरक्षा समूह, त्यसपछि सेवा निजी ठेगानामा सुन्छ कि loopback मा मात्र हेर्नुहोस्। इन्टरनेटतर्फ नियम खोल्नुको सट्टा क्लाइन्ट पूललाई स्रोतका रूपमा अनुमति दिनुहोस्, र Azure Files मा SMB का लागि निजी endpoint को मार्ग टनेलबाट जानुपर्ने सम्झनुहोस्। स्रोतले IP ले जवाफ दिएर नामले नदिए, गेटवे छुनुको सट्टा जाँच 3 मा फर्कनुहोस्।

काम गर्दा एउटा तालिकाले तहहरू अलग राख्छ:

SymptomLayer to check
Name fails, private IP worksResolver setting or forwarder
Private IP also failsAddress plan, NSG, guest firewall
Private works, internet failsExpected; the gateway is not an egress
Connects, then dropsTunnel type or certificate mismatch

जाँच 5: बढाउनुअघि प्रोफाइल रेकर्ड गर्नुहोस्

टिकटमा गेटवे प्रकार, टनेल प्रकार, प्रमाणीकरण विधि र क्लाइन्टको अपरेटिङ सिस्टम लेख्नुहोस्। प्रमाणपत्र भएको IKEv2 प्रोफाइल र RADIUS प्रोफाइल फरक कारणले असफल हुन्छन्, र अर्को टनेल प्रकारका लागि बनाइएको क्लाइन्ट गेटवेले मिल्ने प्रोटोकल दिँदा मात्र जोडिन्छ।

सानो टोलीका लागि टिकाउ डिजाइन एउटा VNet, एउटा DNS forwarder र कागजात गरिएको split-tunnel क्लाइन्ट हो। आवश्यकता स्थिर सार्वजनिक निकास भए, तपाईंले नियन्त्रण गर्ने फायरवालमा साइट-टु-साइट टनेल अन्त्य गरी इन्टरनेट ट्राफिक त्यहाँ राउट गर्नुहोस्, पोइन्ट-टु-साइट गेटवेसँग त्यसका लागि कहिल्यै नबनाइएको काम माग्नुको सट्टा।

सम्बन्धित लेखहरू