कनेक्टेड टनल की एक अवस्था है, पहुँच के बारे में कोई कथन नहीं। पॉइंट-टू-साइट क्लाइंट 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 को निजी एंडपॉइंट का रास्ता टनल से होकर जाना चाहिए। जब कोई संसाधन 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 क्लाइंट है। अगर ज़रूरत स्थिर सार्वजनिक एग्रेस है, तो अपने नियंत्रण वाले फ़ायरवॉल पर साइट-टू-साइट टनल समाप्त करें और इंटरनेट ट्रैफ़िक वहाँ रूट करें, पॉइंट-टू-साइट गेटवे से ऐसा काम माँगने के बजाय जिसके लिए वह कभी बनाया ही नहीं गया।

संबंधित लेख