iPhone पर Always On VPN बनाम VPN On Demand: क्या तैनात करें

दो iPhone दोनों VPN कह सकते हैं और पूरी तरह अलग व्यवहार कर सकते हैं। On Demand नियम मेल खाने पर टनल खोलता है, और उपयोगकर्ता इसे सेटिंग्स में बंद भी कर सकता है। प्रबंधित Always On निगरानी वाले उपकरण पर कवरेज लागू रखता है, उन क्षणों में भी जब टनल ऊपर नहीं आ सकती। उपयोगकर्ता कुछ न करे तब क्या सच होना चाहिए, यह पूछकर चुनें, और फिर स्थिर स्थिति की बजाय संक्रमणों की जाँच करें। नीचे दिए चरण उसी क्रम में हैं जिसमें तैनाती वास्तव में विफल होती है।

चरण 1: तय करें कि उपकरण क्या लागू कर सकता है

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

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

कॉन्फ़िगरेशन छूने से पहले तीन तथ्य लिखें: निगरानी में है या नहीं, प्रबंधित या व्यक्तिगत प्रोफ़ाइल, और कौन सा क्लाइंट टनल ढोता है। हर आगे का चरण इन तीनों पर टिका है, और व्यक्तिगत फोन से व्यवहार प्रबंधित प्रोफ़ाइल में ले जाना ही गलत आधार पर तैनाती मंज़ूर करने का तरीका है।

चरण 2: सुविधा का नाम नहीं, on-demand नियम पढ़ें

On Demand क्रम से आँके जाने वाले नियमों की सूची है। हर नियम एक क्रिया और उसे चुनने वाली शर्तें बताता है, और शर्तें ही दिलचस्प हिस्सा हैं: इंटरफ़ेस का प्रकार, Wi-Fi SSID, DNS डोमेन प्रत्यय या जाँच URL। जो नियम-समूह कभी मेल नहीं खाता वह ऐसी सुविधा है जो कभी जुड़ती नहीं।

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

पूरा सरणी पढ़ें और हर नियम पर दो सवाल पूछें: क्या यह शर्त इस फ्लीट पर कभी सच हो सकती है, और जब कोई नियम मेल न खाए तब क्या होता है? उद्यम नेटवर्क एक्सेस पॉइंट के नाम बदलते हैं, SSID जोड़ते हैं और DNS प्रत्यय बदलते हैं, और इनमें से हर संपादन नियम को वास्तविकता से चुपचाप अलग कर देता है।

DNS प्रत्यय की शर्त मैदान में सबसे ज़्यादा गलत होती है, क्योंकि अतिथि नेटवर्क पर फोन जो प्रत्यय बताता है वह वह नहीं जो कॉर्पोरेट रिज़ॉल्वर परोसता है। नियम पर भरोसा करने से पहले वह नाम जाँचें जो उपकरण वास्तव में हल करता है।

चरण 3: स्थिर कनेक्शन नहीं, संक्रमणों की जाँच करें

जो टनल आप देख रहे हों तब ऊपर है वह बहुत कम साबित करती है। हर संक्रमण जानबूझकर चलाएँ और दर्ज करें कि उपकरण क्या करता है, हर बार वही निजी संसाधन इस्तेमाल करें ताकि परिणाम तुलनीय हों:

• ऐसे नेटवर्क से जुड़ें जहाँ नियम मेल खाना चाहिए, फिर निजी संसाधन मांगें और पुष्टि करें कि वह लोड होता है।
• ऐप पृष्ठभूमि में रखकर सेलुलर पर जाएँ, फिर उसे सामने लाएँ और अनुरोध दोहराएँ।
• कैप्टिव पोर्टल वाले Wi-Fi से जुड़ें और देखें कि पोर्टल पहुँच योग्य है या लागू होना प्रमाणीकरण से पहले उसे रोक देता है।
• निगरानी वाले उपकरण पर टनल हाथ से बंद करें और देखें कि वह अपने आप लौटती है या नहीं, और कितनी जल्दी।

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

चरण 4: विफलता के दो रूप जानें

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

On Demand ट्रिगर न होकर विफल होता है। नियम मेल नहीं खाता, कोई टनल नहीं दिखती, और निजी संसाधन बस समय-सीमा पर समाप्त हो जाता है। इसे सर्वर की समस्या बताकर गलत निदान करना आसान है, क्योंकि क्लाइंट ठीक वैसा ही व्यवहार करता है जैसा कॉन्फ़िगर है।

कैप्टिव पोर्टल दोनों के बीच है: उसे टनल बनने से पहले कनेक्टिविटी चाहिए, इसलिए जो नीति टनल ऊपर आने तक सब कुछ रोकती है उसे पोर्टल से होकर दस्तावेज़ी रास्ता चाहिए। यह डिज़ाइन में तय करें, हेल्प डेस्क पर नहीं।

चरण 5: सत्यापित करें, फिर रोलबैक का अभ्यास करें

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

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

पहले चरण के तीन तथ्य नियम-समूह और परीक्षण परिणामों के पास रखें। जब अगला व्यक्ति पूछे कि फोन एक नेटवर्क पर क्यों जुड़ता है और दूसरे पर नहीं, तो ये नोट्स दोबारा बनाने की बजाय एक मिनट में जवाब देते हैं।