Azure पॉइंट-टू-साइट कनेक्ट होते पण कोणतेही खाजगी संसाधन प्रतिसाद देत नाही
कनेक्टेड म्हणजे फक्त टनेल वर आली. गेटवे काय वाहू शकतो ते तपासा, पत्ता-जागा तुलना करा, मग नाव सोडवा आणि सेवाच तपासा.
कनेक्टेड ही टनेलची अवस्था आहे, पोहोचण्याबद्दलचे विधान नाही. पॉइंट-टू-साइट क्लायंट 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कडे परत जा.
काम करताना एक तक्ता स्तर वेगळे ठेवतो:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
तपासणी 5: एस्केलेट करण्यापूर्वी प्रोफाइल नोंदवा
तिकिटात गेटवे प्रकार, टनेल प्रकार, प्रमाणीकरण पद्धत आणि क्लायंटचे ऑपरेटिंग सिस्टम लिहा. प्रमाणपत्र असलेले IKEv2 प्रोफाइल आणि RADIUS प्रोफाइल वेगवेगळ्या कारणांमुळे अपयशी होतात, आणि दुसऱ्या टनेल प्रकारासाठी बनवलेला क्लायंट गेटवे सुसंगत प्रोटोकॉल देतो तेव्हाच कनेक्ट होतो.
लहान संघासाठी टिकाऊ रचना म्हणजे एक VNet, एक DNS forwarder आणि दस्तऐवजीकृत split-tunnel क्लायंट. आवश्यकता स्थिर सार्वजनिक निर्गम असेल, तर तुम्ही नियंत्रित करता त्या फायरवॉलवर साइट-टू-साइट टनेल संपवा आणि इंटरनेट रहदारी तिथे राउट करा, पॉइंट-टू-साइट गेटवेकडे त्यासाठी कधीही न बांधलेले काम मागण्याऐवजी.