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 मार्गदर्शन मा प्रत्येक सेवाका लागि जोन नाम र रेकर्डको स्वरूप लेखेको छ; अर्को सेवाबाट जोन प्रतिलिपि गर्नुको सट्टा आफ्नो सेवाको प्रविष्टि पढ्नुहोस्।