उस सहेजी गई Mac VPN प्रोफ़ाइल के पीछे कौन-सा प्रोटोकॉल है?

कोई Mac कनेक्शन को «ऑफ़िस VPN» कहता है, लेबल दो सर्वर माइग्रेशन पार कर जाता है, और प्रोटोकॉल बदलने के बहुत बाद तक सब उसे ऑफ़िस VPN ही कहते रहते हैं। नाम कॉन्फ़िगरेशन के पास सहेजा गया उपनाम है; यह प्रमाण नहीं है कि Mac किस पर बातचीत करता है। घोषित प्रकार पढ़ने में एक फ़ील्ड लगता है, और उस सहेजे गए प्रकार को जीवंत सत्र से अलग करने में एक और कदम। यह वह क्रम है जो अनुमान से बचता है।

लेबल उपनाम है, पेलोड प्रकार घोषित करता है

macOS VPN सेवा एक सिस्टम कॉन्फ़िगरेशन प्रविष्टि है जिसमें प्रदर्शित नाम, स्वामी क्लाइंट और टाइप किए गए सेटिंग्स का समूह होता है। प्रदर्शित नाम मुक्त पाठ है, जिसे प्रविष्टि बनाने वाला कोई भी संपादित कर सकता है, और उपयोगकर्ता मेनू बार में यही भाग देखते हैं। सेटिंग्स तथ्य रखती हैं: कौन-सा कनेक्शन प्रकार, कौन-सा गेटवे, कौन-सी प्रमाणीकरण व्यवस्था। कुछ भी दोनों को तालमेल में नहीं रखता, इसलिए «L2TP ऑफ़िस» नाम की प्रोफ़ाइल IKEv2 सेवा हो सकती है।

व्यक्तिगत रूप से बनाए गए कनेक्शन के लिए, स्वामी एप्लिकेशन या सिस्टम का अपना VPN पैनल वे सेटिंग्स दिखाता है। प्रबंधित Mac पर प्रोफ़ाइल प्रशासक की होती है, और सही कदम है प्रबंधित पेलोड संपादित करने के बजाय गैर-गोपनीय सारांश माँगना। दोनों स्थितियाँ मेनू बार में एक जैसी दिखती हैं और नीचे बिल्कुल अलग व्यवहार करती हैं। एक आपकी है जाँचने और बदलने के लिए; दूसरी तैनात है और अगली जाँच में बहाल हो जाएगी।

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

पेलोड में बाकी सब से पहले VPNType पढ़ें

Apple की प्रबंधित VPN पेलोड स्कीमा अपना कनेक्शन प्रकार VPNType कुंजी में घोषित करती है, ऐसे शब्दकोश के अंदर जिसका PayloadType com.apple.vpn.managed है। मान एक छोटा टोकन है जैसे IKEv2, IPsec, L2TP या VPN, और पेलोड में बाकी सब उसी टोकन के अनुसार व्याख्यायित होता है।

<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>VPNType</key>
<string>IKEv2</string>
<key>IKEv2</key>
<dict>
  <key>RemoteAddress</key>
  <string>vpn.head-office.example</string>
  <key>RemoteIdentifier</key>
  <string>ikev2.head-office.example</string>
</dict>

यह अंश उदाहरणात्मक है, इंस्टॉल करने योग्य नहीं: यह पेलोड सरणी की एक प्रविष्टि है, जिससे वास्तविक तैनाती को ज़रूरी प्रोफ़ाइल मेटाडेटा और क्रेडेंशियल हटा दिए गए हैं। इसे आकार के लिए पढ़ें, सामग्री के लिए नहीं। यह भी ध्यान दें कि RemoteAddress और RemoteIdentifier अलग-अलग काम वाले अलग फ़ील्ड हैं, तब भी जब कोई तैनाती उन्हें एक ही स्ट्रिंग देती है।

पुराना मान, जैसे PPTP, अभी भी पुरानी फ़ाइल में दिख सकता है, बिना ऐसा विकल्प होने जो मौजूदा macOS नई कॉन्फ़िगरेशन के लिए देता हो। सहेजी गई प्रोफ़ाइल में टोकन मिलना यह साबित करता है कि क्या लिखा गया था, यह नहीं कि ऑपरेटिंग सिस्टम अब भी क्या स्वीकार करेगा।

कस्टम प्रकारों को VPNSubType और स्वामी ऐप चाहिए

जब VPNType VPN होता है, तब पेलोड को VPNSubType भी रखना होता है, जो कनेक्शन लागू करने वाले प्लग-इन या Network Extension प्रदाता की पहचान करता है। यही पहचानकर्ता कनेक्शन को किसी विशेष क्लाइंट तक भेजता है, इसलिए ग़लत उपप्रकार ऐसी प्रोफ़ाइल बनाता है जो इंस्टॉल होती है और फिर शुरू होने से इनकार कर देती है।

ऐप-एक्सटेंशन आधारित प्रदाताओं में पहचानकर्ता अनुमानित एक्सटेंशन नाम का नहीं, बल्कि समाहित करने वाले ऐप का होता है, और यही वह ब्यौरा है जिसे लोग प्रोफ़ाइल हाथ से संपादित करते समय आमतौर पर ग़लत करते हैं। सही उपप्रकार भी क्लाइंट का वर्णन करता है, तार प्रोटोकॉल, प्रमाणीकरण विधि या उस क्लाइंट द्वारा उपयोग की जाने वाली दूरस्थ पहुँच नीति का नहीं।

इसलिए कस्टम पेलोड आपको बताता है कि कनेक्शन किस सॉफ़्टवेयर का है और थोड़ा और नहीं। यह किस पर बातचीत करता है, यह जानने के लिए उस प्रदाता का अपना दस्तावेज़ और उसकी कॉन्फ़िगर की गई सेटिंग्स पढ़ें। दूसरे संगठन की प्रोफ़ाइल से उपप्रकार कॉपी करना कॉन्फ़िगरेशन तकनीक नहीं है; यह एक अनुमान है जो संयोग से पार्स हो जाता है।

सूची बनाएँ कि Mac ने वास्तव में क्या कॉन्फ़िगर किया है

कोई भी फ़ाइल पढ़ने से पहले सिस्टम से पूछें कि कौन-सी सेवाएँ मौजूद हैं और किस स्थिति में हैं। कमांड-लाइन दृश्य पैनलों में क्लिक करने से तेज़ है और यह हर प्रविष्टि के आगे प्रकार छापता है।

scutil --nc list
scutil --nc show "Office VPN"

पहला कमांड कॉन्फ़िगर की गई VPN सेवाओं को उनकी मौजूदा स्थिति के साथ सूचीबद्ध करता है, और दूसरा चयनित सेवा की सेटिंग्स छापता है, जिनमें प्रकार और वह सर्वर पता शामिल है जिससे वह संपर्क करेगी। उस पते की तुलना उस गेटवे से करें जिसकी आपको अपेक्षा बताई गई थी, क्योंकि सेवानिवृत्त होस्ट की ओर इशारा करने वाली पुरानी प्रविष्टि आम विरासत समस्या है।

ये कमांड कॉन्फ़िगरेशन और स्थिति दिखाते हैं; वे यह साबित नहीं करते कि कोई सुरंग ट्रैफ़िक ले जा रही है। यदि सेवा डिस्कनेक्ट है, तो आउटपुट काम कर रहे सत्र के बजाय इरादे का वर्णन करता है। ट्रैफ़िक के बिना जुड़ी सेवा फिर एक और समस्या है, आमतौर पर राउटिंग या DNS, प्रोटोकॉल प्रकार नहीं। इन तीन अवलोकनों को अलग रखें, वरना निदान फिर अनुमान में बदल जाएगा।

सहेजी गई सेटिंग्स को जीवंत सत्र से अलग रखें

सहेजी गई प्रोफ़ाइल इरादे का बयान है। यह नहीं दिखाती कि गेटवे अब भी वह सेवा देता है, कि यही प्रोफ़ाइल सक्रिय है, या कि किसी सत्र ने सफलतापूर्वक बातचीत की। ये तीन अलग प्रश्न हैं और हर एक का अपना प्रमाण है।

सक्रिय कनेक्शन और गेटवे द्वारा प्रस्तुत पहचान की पहचान करने के लिए स्वामी का स्थिति दृश्य या निदान उपकरण उपयोग करें। पोर्ट स्कैन या किसी असंबंधित साइट पर देखा गया प्रमाणपत्र दोनों में से किसी प्रश्न का उत्तर नहीं देता, और प्रमाणपत्र का सामान्य नाम अपेक्षित दूरस्थ पहचानकर्ता के बराबर नहीं है।

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