Azure P2S VPN खाजगी एंडपॉइंटचे नाव सोडवू शकत नाही

तुम्ही point-to-site टनेल जोडता, खाजगी पत्त्यावर ping करता, अ‍ॅप उघडता आणि त्याऐवजी 403 किंवा प्रमाणपत्र त्रुटी मिळते. दोन्ही लक्षणे DNS कडे निर्देश करतात, पण त्या वेगळ्या बिघाड्या आहेत: एकाचा अर्थ क्लायंटने सार्वजनिक पत्ता सोडवला, दुसऱ्याचा अर्थ खाजगी पत्ता सोडवून नंतर प्रमाणपत्र व्यापत नाही असे नाव दिले. खालील तपासण्या क्रमाने करा आणि पहिल्या अपयशावर थांबा, कारण hosts नोंद किंवा कॅशेमधील उत्तर पुढील प्रत्येक तपासणी चुकीच्या कारणाने पास करू शकते. हा क्रम मी माझ्या VPN प्रोफाइल्सच्या शेजारी टेक्स्ट फाइलमध्ये ठेवतो, कारण दुरुस्ती टनेलमध्ये काहीही बदलत नाही आणि क्लायंटला जे माहीत आहे त्यात सर्व बदलते.

क्लायंटला प्रत्यक्षात मिळणाऱ्या पत्त्यापासून सुरुवात करा

अ‍ॅपवर विश्वास ठेवण्याऐवजी रिझोल्व्हरला थेट विचारा. Windows वर, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net क्लायंटला कोणते दृश्य मिळाले ते दाखवते. सार्वजनिक उत्तर म्हणजे पुढे काहीही एंडपॉइंटपर्यंत पोहोचणार नाही; एंडपॉइंटचा खाजगी पत्ता म्हणजे DNS संपले आणि पुढील तपासणी ही कनेक्शन स्वतःच आहे.

खाजगी एंडपॉइंट सेवेचे नाव बदलत नाही. खाते किंवा अ‍ॅप त्याचे नेहमीचे पूर्ण पात्र नाव ठेवते, आणि एंडपॉइंट व्हर्च्युअल नेटवर्कमधील क्लायंटसाठी ते नाव ज्या पत्त्यावर सोडवले जाते तो पत्ता फक्त बदलते. म्हणूनच तेच होस्टनेम नेटवर्कमधील VM वरून खाजगी आणि खाजगी दृश्य कधीही न मिळालेल्या लॅपटॉपवरून सार्वजनिकरित्या सोडवले जाते.

टनेलपूर्वी झोन, त्याची लिंक आणि रेकॉर्ड तपासा

तीन अटी एकत्र पूर्ण व्हायला हव्यात: खाजगी झोन आहे, VPN गेटवे आणि क्लायंट Azure मध्ये प्रवेश करतात त्या व्हर्च्युअल नेटवर्कशी तो जोडलेला आहे, आणि त्यात एंडपॉइंटसाठी खाजगी पत्त्याकडे निर्देश करणारा A रेकॉर्ड आहे. झोन असंबंधित नेटवर्कशी जोडल्यास गेटवे सार्वजनिक रेकॉर्ड सोडवत राहील, पण टनेलवरील सर्व काही निरोगी दिसेल.

झोनची नावे सेवांशी संबंधित आहेत, सर्वसाधारणपणे खाजगी लिंकशी नाहीत. App Service सहसा privatelink.azurewebsites.net वापरते, स्टोरेज आणि SQL ची स्वतःची नावे आहेत, आणि दुसऱ्या सेवेचा झोन उसनवार घेतल्यास अस्तित्वात असलेला पण काहीही उपयुक्त उत्तर न देणारा झोन तयार होतो.

क्लायंटला प्रत्यक्षात पोहोचू शकेल असा रिझोल्व्हर द्या

168.63.129.16 Azure व्हर्च्युअल मशीनमधून उत्तर देते आणि point-to-site टनेलच्या पलीकडील लॅपटॉपसाठी DNS सर्व्हर नाही. क्लायंटला टनेलमधून पोहोचणारा रिझोल्व्हर हवा: Azure DNS Private Resolver चा इनबाउंड एंडपॉइंट, व्हर्च्युअल नेटवर्कमधील फॉरवर्डर, किंवा VPN क्लायंट प्रोफाइलमध्ये नेलेल्या DNS सर्व्हर नोंदी, जेणेकरून क्लायंट व्हर्च्युअल नेटवर्कला थेट विचारेल.

कॉन्फिगर केलेला पण पोहोच नसलेला रिझोल्व्हर कोणताही रिझोल्व्हर नसल्यासारखाच वागतो, आणि लक्षण चुकीचे उत्तर नसून टाइमआउट असते, म्हणूनच ते फायरवॉल समस्या म्हणून चुकीचे वाचले जाते. टनेलने वाहून नेण्याची अपेक्षा असलेल्या क्वेरीने तपासा, स्थानिक लिंकवरून तरीही यशस्वी होणाऱ्या सार्वजनिक नावाने नाही.

सेटिंग्ज ढकलण्याऐवजी फॉरवर्ड करत असल्यास, खाजगी झोनकडे असलेली नावांची जागा फॉरवर्ड करा, संपूर्ण azurewebsites.net ऐवजी privatelink.azurewebsites.net. संपूर्ण पालक प्रत्यय गिळणारा सशर्त फॉरवर्डर सेवेचा प्रत्येक शोध Azure कडे पाठवतो, स्थानिक राहायला हव्या त्या शोधांसह.

ज्या नावासाठी प्रमाणपत्र जारी झाले ते वापरा

पत्ता बरोबर झाल्यावर दुसरी बिघाड समोर येते. स्टोरेज आणि App Service privatelink उपनाव प्रकाशित करतात, आणि ते उपनाव प्रमाणपत्रातील नावच असेल असे नाही. privatelink.blob.core.windows.net वर पाठवलेला AzCopy अपलोड प्रमाणीकरणात अपयशी ठरला; तोच अपलोड <account>.blob.core.windows.net/<container> वर खाजगी पत्त्यावर सोडवला गेला आणि पास झाला, त्यामुळे तो कोणत्याही बायपासशिवाय खाजगी मार्गावर राहिला.

हा नियम ब्राउझरमध्ये आणि App Service साठीही लागू आहे: प्रमाणपत्र व्यापणाऱ्या होस्टनेमने कनेक्ट व्हा आणि DNS ला खाजगी पत्ता द्यायला द्या. प्रमाणीकरण टाळण्याकडे वळू नका, कारण ते नावकरणाची चूक सुरक्षा घट बनवते. यशस्वी ping मार्ग सिद्ध करते आणि हातमिळवणीतील नावाबद्दल काहीही सांगत नाही, म्हणूनच ही स्वतंत्र तपासणी राहतात.

प्रत्येक स्तर वेगळा करणारा चार पायऱ्यांचा क्रम

1. VPN क्लायंटकडे point-to-site पूलमधून पत्ता आणि एंडपॉइंटच्या खाजगी पत्त्यापर्यंत मार्ग आहे याची खात्री करा.
2. अ‍ॅप वापरते तेच नेमके नाव सोडवा आणि उत्तराची एंडपॉइंटच्या पत्त्याशी तुलना करा.
3. सेवा पोर्टवर एंडपॉइंटशी TCP कनेक्शन उघडा, नंतर त्या कनेक्शनवर सादर केलेले प्रमाणपत्र नाव वाचा.
4. आता एवढेच अधिकृतता तपासा, कारण चालणारा मार्ग आणि वैध प्रमाणपत्र अजून संसाधनात प्रवेश देत नाहीत.

पत्ता बरोबर असताना नाकारलेले कनेक्शन DNS कडे नाही तर नेटवर्क सुरक्षा गट किंवा खाजगी एंडपॉइंट कनेक्शनच्या स्थितीकडे निर्देश करते, म्हणून रिझोल्व्हर सेटिंग्ज पुन्हा संपादित करण्यापूर्वी त्या तपासा. TLS नावाची विसंगती तुम्हाला URL मधील होस्टनेम आणि प्रमाणपत्राच्या subject कडे परत पाठवते. सोडवण्याचे आउटपुट, प्रमाणपत्राचे नाव आणि नेमका URL एकत्र ठेवा; ही तीन मूल्ये गेटवेला हात न लावता यापैकी बहुतेक प्रकरणे स्पष्ट करतात.

नियंत्रण म्हणून व्हर्च्युअल नेटवर्कमधील VM वापरा. नाव तिथे खाजगी आणि टनेलमधून सार्वजनिक सोडवले जात असेल, तर झोन आणि रेकॉर्ड बरोबर आहेत आणि एकमेव फरक क्लायंटचा रिझोल्व्हर मार्ग आहे, जो एंडपॉइंट कॉन्फिगरेशनवर आणखी एक फेरी मारण्यापेक्षा लवकर निश्चित होतो.

क्लायंटही कॅशे करतात. दहा मिनिटांपूर्वी सार्वजनिक उत्तर दिलेला रेकॉर्ड झोन दुरुस्त केल्यावरही उत्तर देत राहतो, म्हणून पुन्हा तपासण्यापूर्वी कॅशे रिकामी करा. Windows वर, ipconfig /flushdns क्लायंट कॅशे साफ करते; नाव सोडवण्याच्या धोरणाचे नियम टिकतात, कोणता प्रत्यय कोणत्या सर्व्हरकडे जातो हे ठरवतात आणि तुम्ही नुकतेच बदललेल्या रिझोल्व्हरकडे नावांची जागा पाठवत राहू शकतात.

hosts नोंद कुठे असावी

एंडपॉइंटचा पत्ता hosts फाइलमध्ये जोडणे चांगले निदान आणि वाईट रचना आहे. ते नाव-ते-पत्ता जुळणी हाच गहाळ तुकडा आहे हे सिद्ध करते आणि त्या पायरीनंतर सर्व काही तपासू देते, पण ते तुमच्या वापरकर्त्यांना अदृश्य आहे, एंडपॉइंटचा पत्ता बदलल्यास तुटते आणि उत्तर द्यायला हवा तो झोन लपवते.

उरलेली चाचणी नोंद जुन्या कॅशेपेक्षा वाईट आहे, कारण त्रुटीच्या दिशेनुसार ती दुरुस्त मार्ग तुटलेला किंवा तुटलेला मार्ग दुरुस्त दाखवू शकते. अंतिम फेरीपूर्वी ती काढा आणि फक्त उत्पादन रिझोल्व्हरने सोडवा.

लहान नावांना शोध प्रत्यय लागतो आणि पूर्ण पात्र नावांना लागत नाही, म्हणून आधी पूर्ण पात्र नाव तपासा, नंतर कार्यप्रवाहाला क्लायंट प्रोफाइलमधून ढकलला जाणारा प्रत्यय हवा का हे ठरवा. Microsoft त्याच्या खाजगी एंडपॉइंट DNS मार्गदर्शनात प्रत्येक सेवेसाठी झोन नावे आणि रेकॉर्डचे स्वरूप नोंदवते; दुसऱ्या सेवेचा झोन कॉपी करण्याऐवजी तुमच्या सेवेची नोंद वाचा.