macOS पर VPN प्रोफ़ाइल आयात नहीं होती: पहले पेलोड पढ़ें
एक Mac पर अस्वीकृत और दूसरे पर स्वीकृत प्रोफ़ाइल आमतौर पर पेलोड की समस्या होती है। XML की तुलना करें, देखें कि जनरेटर ने क्या जोड़ा, और फिर सेवा सत्यापित करें।
जब कोई प्रोफ़ाइल एक Mac पर बिना अड़चन के इंस्टॉल हो जाती है और दूसरे पर अस्वीकार कर दी जाती है, तो नेटवर्क तक पहुँच ही नहीं हुई है, इसलिए प्रमाणपत्र, गेटवे और पासवर्ड को कोई दोष नहीं देना चाहिए। इंस्टॉलर उस पेलोड पर रुक गया जिसे वह स्वीकार नहीं करता था, और आमतौर पर दर्ज करता है कि कौन-सा था। इससे प्रोफ़ाइल फ़ाइल और जिसने भी उसे बनाया, काम करने के एकमात्र उचित स्थान रह जाते हैं, और क्लाइंट पर सेटिंग्स मिटाना मरम्मत के बजाय सबूत नष्ट करने का तरीका बन जाता है।
Mac को रीसेट करने के बजाय प्रोफ़ाइल पढ़ें
.mobileconfig निर्यात करें और क्लाइंट को छूने से पहले देखें कि उसमें वास्तव में क्या है:
plutil -p profile.mobileconfig | head -60
VPN प्रोफ़ाइल वास्तव में अलग-अलग काम करने वाले दो पेलोड हैं: com.apple.vpn.managed कनेक्शन रखता है, और com.apple.dnsSettings.managed रिज़ॉल्वर कॉन्फ़िगरेशन रखता है। इंस्टॉलेशन उस पहले पेलोड पर रुक जाता है जिसे इंस्टॉलर अस्वीकार करता है, और अस्वीकृति उस पेलोड के नाम के साथ सिस्टम लॉग में दर्ज होती है, इसलिए लॉग ही बताता है कि कौन-सा अनुभाग खोलना है। अंतिम बार सफलतापूर्वक आयात हुई प्रोफ़ाइल की एक प्रति रखें, क्योंकि वही फ़ाइल आपके अंतर को मापने का आधार है।
जनरेटर ने चुपचाप क्या जोड़ा
Apple Configurator 2.15 बिल्ड 7A23 ने अपने DNS पेलोड के भीतर निम्न ब्लॉक जारी किया:
<key>DNS</key>
<dict>
<key>SupplementalMatchDomainsNoSearch</key>
<integer>0</integer>
</dict>
macOS 12.1 पर उस बिल्ड द्वारा लिखी गई प्रोफ़ाइलें आयात के समय अस्वीकार कर दी गईं। Configurator 2.11.1 से बना कनेक्शन बिना किसी शिकायत के अंदर चला गया, क्योंकि वह संस्करण कुंजी को बिल्कुल नहीं लिखता था। पूरा DNS शब्दकोश या केवल समस्या वाली कुंजी हटाएँ, फिर से सहेजें, और फिर कुछ और बदलने से पहले उसी मशीन पर दोबारा आज़माएँ। आमतौर पर वही एक संपादन पूरी मरम्मत होता है।
इस उपकरण में एक जाल है जिसे उस पर भरोसा करने से पहले जानना अच्छा है। कुंजी हटने के बाद उसी कनेक्शन को सहेजने से वह वापस नहीं आई, और वह केवल तब फिर दिखी जब कनेक्शन शून्य से बनाया गया। हर नई बनी प्रोफ़ाइल को संदिग्ध मानें और उसकी जाँच करें, विशेषकर जब एक ही बैठक में कनेक्शनों का पूरा बैच बनाया गया हो।
MDM मार्ग कहीं और विफल होता है
वही प्रोफ़ाइल धकेलने वाली प्रबंधन सेवा किसी दूसरी जगह विफल हो सकती है: क्लाइंट शिकायत करता है कि कोई VPN सेवा ही नहीं बनी। जिस मामले की सूचना मिली उसमें प्रमाणपत्र प्रमाणीकरण के लिए कॉन्फ़िगर किया गया पेलोड फिर भी पासवर्ड फ़ील्ड माँग रहा था; उसे प्लेसहोल्डर से भरने पर प्रोफ़ाइल लागू हुई, और किसी ने कभी उस मान का उपयोग प्रमाणीकरण के लिए नहीं किया।
यदि आप वह मार्ग लें, तो एक डमी स्ट्रिंग रखें और कभी वास्तविक क्रेडेंशियल नहीं, और असली रहस्य प्रोफ़ाइल के मुख्य भाग से बाहर रखें। काम करने वाला पासवर्ड लिए प्रोफ़ाइल ऐसी फ़ाइल बन जाती है जिसे कुंजी की तरह सुरक्षित रखना पड़ता है, और यह उस विफल आयात से कहीं बड़ी समस्या है जिससे आपने शुरुआत की। प्रोफ़ाइल वितरित होने से पहले तय करें कि वह प्लेसहोल्डर किसका है, ताकि बाद में कोई उसे बदलने योग्य मान न समझे। यह क्यों मौजूद है, इसका दस्तावेज़ीकरण एक पंक्ति लेता है और छह महीने बाद एक बहस बचाता है।
पुष्टि करें कि प्रोफ़ाइल वास्तव में पहुँची
सफल आयात का अर्थ काम करने वाली सेवा नहीं है, इसलिए इस क्रम में जाँचें:
profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20
पहला आदेश इंस्टॉल किए गए पेलोड की सूची देता है; दूसरा बताता है कि क्या कोई VPN सेवा है ही। अंतिम, कनेक्ट करने के बाद चलाया गया, वह रिज़ॉल्वर दिखाता है जिसका उपयोग सिस्टम वास्तव में करेगा। इन्हें उसी क्रम में पढ़ें और वहीं रुकें जहाँ श्रृंखला टूटती है, क्योंकि सेवा न होना रिज़ॉल्वर के बारे में हर सवाल को अर्थहीन बना देता है। कोई प्रोफ़ाइल इंस्टॉल के रूप में सूचीबद्ध हो सकती है और फिर भी उपयोगी कुछ भी न रखती हो, और यही वह स्थिति है जिसे उजागर करने के लिए यह क्रम बनाया गया है।
यदि टनल तब उठे जब किसी सेवा प्रविष्टि के पास अभी तक कोई उपयोगी नाम न हो, तो प्रदर्शित नाम वाला फ़ील्ड निर्यात में खो गया है, और उपाय क्लाइंट पर नाम बदलना नहीं बल्कि प्रोफ़ाइल को फिर से बनाना है। यदि रिज़ॉल्वर स्थानीय की ओर ही इशारा करता रहे, तो DNS पेलोड आपकी मंशा से अधिक गहराई से हटाया गया है।
रोलआउट चरणों में करें, एक समय में एक Mac
एक प्रबंधित Mac पर उसी OS बिल्ड के साथ इंस्टॉल करें, फिर तीन बातें अलग-अलग जाँचें: सेवा दिखाई देती है, रिज़ॉल्वर बदलता है, और एक वास्तविक आंतरिक अनुरोध सफल होता है। तीनों के बाद ही दायरा बढ़ाना चाहिए।
ये तीन अलग परिणाम हैं जो तीन अलग तरीकों से विफल होते हैं, और इसी कारण एक परीक्षण मशीन उन दस मिनटों के लायक है। आयात होने वाली प्रोफ़ाइल काम करने वाली प्रोफ़ाइल नहीं है, और पहले चरण की मशीन बाकी बेड़े को कुछ भी दिखने से पहले दोनों तरह की विफलताएँ पकड़ लेती है।