Mac पर Azure VPN Client: DNS सर्वर प्रोफ़ाइल में रखें

macOS पर तीन अलग सवालों का जवाब एक ही कंधा-झटके से दिया जाता है। यह कौन-सा क्लाइंट है? इसके DNS सर्वर कहाँ से आते हैं? और सेटिंग जगह पर आ जाने के बाद भी छोटा नाम क्यों विफल रहता है? इनके जवाब अलग-अलग हैं, और सिर्फ़ पहला प्रोफ़ाइल फ़ाइल के बारे में है। सही क्रम एक अस्पष्ट DNS समस्या को एक बार में एक सत्यापन-योग्य कदम में बदल देता है।

पुष्टि करें कि आप कौन-सा क्लाइंट कॉन्फ़िगर कर रहे हैं

यह Microsoft का Azure VPN Client है, जो पॉइंट-टू-साइट पहुँच के लिए OpenVPN का उपयोग करता है। इसका XML macOS का मूल IKEv2 प्रोफ़ाइल नहीं है, और यह किसी भी तीसरे पक्ष के OpenVPN क्लाइंट के लिए कॉन्फ़िगरेशन फ़ाइल भी नहीं है।

अगर Mac अंतर्निहित सिस्टम डायलॉग से जुड़ता है, तो आप गलत दस्तावेज़ में हैं।

DNS प्रोफ़ाइल XML के अंदर रहता है

इच्छित गेटवे और प्रमाणीकरण विधि के लिए मौजूदा प्रोफ़ाइल डाउनलोड करें, फिर कुछ भी छूने से पहले एक अपरिवर्तित प्रति रखें। केवल कार्यशील प्रति को संपादित करें, और उसकी प्रमाणीकरण सामग्री को सहायता टिकट में न चिपकाएँ।

वैकल्पिक सेटिंग्स गाइड DNS प्रविष्टियों को clientconfig एलिमेंट के अंदर रखता है। एक न्यूनतम टुकड़ा ऐसा दिखता है, ऐसे पते के साथ जिसे आपका संगठन वास्तव में चलाता है।

<clientconfig>
    <dnsservers>
        <dnsserver>10.20.2.4</dnsserver>
    </dnsservers>
</clientconfig>

वह पता उदाहरण के लिए है, Azure द्वारा दिया गया रिज़ॉल्वर नहीं। दूसरा clientconfig एलिमेंट चिपकाने के बजाय प्रविष्टियों को मौजूदा कॉन्फ़िगरेशन में एकीकृत करें, क्योंकि Microsoft कहता है कि macOS पर डुप्लिकेट एलिमेंट समर्थित नहीं हैं। जनरेट किए गए प्रोफ़ाइल में जहाँ असली कॉन्फ़िगरेशन होना चाहिए वहाँ nil प्लेसहोल्डर भी हो सकता है, और nil एलिमेंट के बगल में सेटिंग्स जोड़ना मरम्मत नहीं है।

आयात ही बदलाव है

फ़ाइल सहेजने से अपने आप कुछ नहीं बदलता। Azure VPN Client खोलें, Import चुनें, संशोधित XML चुनें, ज़रूरी फ़ील्ड भरें और कनेक्शन सहेजें।

फिर उसी आयातित कनेक्शन से दोबारा जुड़ें। डिस्क पर प्रोफ़ाइल पड़ा रहना जबकि पुराना कनेक्शन सक्रिय रहे, सही संपादन के कुछ न करने जैसा दिखने का सबसे आम कारण है।

सफ़िक्स सीमा आपका पहला परीक्षण तय करती है

जैसा 30 अक्तूबर 2026 को प्रलेखित है, इस कॉन्फ़िगरेशन में अतिरिक्त DNS सफ़िक्स मान macOS पर ठीक से नहीं टिकते। Windows का सफ़िक्स उदाहरण कॉपी करके वैसा ही व्यवहार का वादा करना वही तरीका है जिससे काम करने वाला रिज़ॉल्वर टूटा हुआ बताया जाता है। सफ़िक्स दर्ज करें, सहेजें, फिर से जुड़ें और देखें कि वे पुनःकनेक्शन के बाद बचे या नहीं। अगर नहीं बचे, तो क्लाइंट से लड़ने के बजाय पूर्णतः योग्य नामों के साथ योजना बनाएँ।

पहले पूर्णतः योग्य निजी होस्टनाम से परीक्षण करें। अगर FQDN हल होता है और छोटा नाम नहीं, तो आपने कुछ ख़ास सीखा: रिज़ॉल्वर पहुँच में है और छोटे नाम का विस्तार गायब है। यह पहुँच से बाहर DNS सर्वर से अलग ख़राबी है, और इसके लिए अलग ज़िम्मेदार व्यक्ति चाहिए।

रिज़ॉल्वर को अब भी पथ चाहिए

XML में पता सूचीबद्ध करना DNS सेवा नहीं बनाता। पते पर एक अधिकृत रिज़ॉल्वर चलना चाहिए जो निजी नामस्थान का जवाब दे सके या उसे अग्रेषित कर सके, और Mac को टनल से वहाँ पहुँचने की अनुमति होनी चाहिए। अगर वह रिज़ॉल्वर ऐसे फ़ायरवॉल नियम के पीछे है जो टनल की सीमा नहीं जानता, तो क्वेरी बिना किसी उपयोगी त्रुटि के समय-समाप्त हो जाती हैं। तब समय-समाप्ति बिल्कुल गलत पते जैसी दिखती है, और लोग एक घंटे तक XML फिर से संपादित करते हैं।

जुड़े हुए Mac की सक्रिय रिज़ॉल्वर स्थिति देखें, फिर उस सर्वर से सीधे पूछें ताकि उसका जवाब ऐप के रिज़ॉल्वर चयन से अलग हो जाए। सीधी क्वेरी साबित करती है कि सर्वर काम करता है। यह साबित नहीं करती कि सामान्य लुकअप उसे चुनते हैं।

तीन अलग परिणाम सौंपें

सौंपते समय इन्हें अलग रखें: संशोधित प्रोफ़ाइल आयात हुआ, इच्छित रिज़ॉल्वर ने माँगे गए नाम का जवाब दिया, और ऐप लौटाए गए पते तक पहुँचा। हर एक का अलग ज़िम्मेदार और अलग समाधान है।

हर परिणाम के लिए एक पंक्ति काफ़ी है, और यह अगले व्यक्ति को ऐसी प्रोफ़ाइल दोबारा संपादित करने से रोकती है जो पहले से सही थी।