iOS VPN API: NEVPNManager, टनल प्रोवाइडर या प्रोफ़ाइल?

जिस ट्रांसपोर्ट से आपको बात करनी है उसके आधार पर API चुनें, फिर साबित करें कि टनल ट्रैफ़िक ले जाती है: save-load-start क्रम, provider entitlements और on-demand नियम।

तीन अलग-अलग उत्पाद iOS VPN नाम का जवाब देते हैं, और वे एक ही API साझा नहीं करते। Personal VPN सिस्टम के अंतर्निहित IPsec और IKEv2 ट्रांसपोर्ट पर चलता है। Custom tunnel आपका अपना प्रोटोकॉल network extension के अंदर चलाता है। Configuration profile इनमें से किसी एक को कॉन्फ़िगर करता है और on-demand व्यवहार जोड़ सकता है। जिस ट्रांसपोर्ट से आपको बात करनी है, उसके आधार पर चुनना उस ट्यूटोरियल के आधार पर चुनने से तेज़ है जो पहले कंपाइल हुआ।

नीचे दिए गए जाँचों को क्रम में चलाएँ, क्योंकि हर चरण मानता है कि पिछले चरण ने एक मान्य कॉन्फ़िगरेशन बनाया।

चरण 1: ट्रांसपोर्ट के आधार पर चुनें

अगर सर्वर IKEv2 या Cisco-शैली का IPsec है, तो NEVPNManager पर्याप्त है और सिस्टम ट्रांसपोर्ट मुफ़्त में मिलते हैं। अगर सर्वर OpenVPN, WireGuard या कुछ और बोलता है, तो NEVPNManager मदद नहीं कर सकता: इसके पास तीसरे पक्ष के प्रोटोकॉल के लिए कोई हुक नहीं है। उस स्थिति में NETunnelProviderManager चाहिए, साथ में एक packet tunnel provider जो प्रोटोकॉल लागू करे। Profile केवल कॉन्फ़िगरेशन बाँटता है, और ऑपरेटिंग सिस्टम के पास जो ट्रांसपोर्ट नहीं है उसे वह नहीं जोड़ सकता।

मौजूदा सिस्टम पर PPTP लक्ष्य नहीं है। Shared-secret IPsec अभी भी remoteIdentifier में समूह का नाम, गुप्त कुंजी रखने वाला keychain आइटम, और सर्वर के उपयोगकर्ता नाम माँगने पर विस्तारित प्रमाणीकरण की अपेक्षा करता है। हर गायब टुकड़ा उसी सामान्य कॉन्फ़िगरेशन त्रुटि के रूप में सामने आता है, इसलिए कुछ और डीबग करने से पहले उन सबको जोड़ें।

चरण 2: save, load, start क्रम का पालन करें

NEVPNManager preferences में लिखता है, उन्हें वापस पढ़ता है, और तभी शुरू होता है। Protocol और manager ऑब्जेक्ट भरें, saveToPreferences कॉल करें, loadFromPreferences कॉल करें, और load completion handler से startVPNTunnel कॉल करें। Load लौटने से पहले शुरू करना उस कॉन्फ़िगरेशन पर configuration-invalid त्रुटि, NEVPNErrorDomain code 1, पैदा करता है जो अन्यथा सही है।

आकार इतना छोटा है कि इसे एक ही जगह रखा जा सके:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel तब लौटता है जब अनुरोध स्वीकार होता है, तब नहीं जब टनल ऊपर हो। NEVPNStatusDidChange देखें और असली स्थिति के लिए connection.status पढ़ें। जो ऐप कॉल साइट पर सफलता मान लेता है, वह VPN को कनेक्टेड बताता है जबकि extension अभी बातचीत कर रहा होता है। Connecting स्थिति एक पल के लिए सामान्य है; जो स्थिति उससे कभी नहीं निकलती, वही लॉग करने लायक विफलता है।

चरण 3: provider प्रक्रिया को वह दें जो उसे चाहिए

Custom transport अलग प्रक्रिया में अपने bundle identifier और अपने entitlement के साथ चलता है। Container ऐप और provider दोनों को साइनिंग के समय network-extension entitlement चाहिए, और App Store के बाहर Developer ID बिल्ड को भी उसे provisioning profile में रखना ही होता है। गायब entitlement प्रोटोकॉल बग जैसा दिखता है क्योंकि extension बस शुरू ही नहीं होता।

उधार लेने के लिए कोई सार्वजनिक socket descriptor नहीं है। NEPacketTunnelProvider आपको read, write और cancel के साथ NEPacketTunnelFlow देता है, और private key paths तक पहुँचने वाला कोड रिलीज़ के बीच टूट जाता है। ऐप बैकग्राउंड में होने पर भी provider चलता रहता है, इसलिए container ऐप को उसके लिए किसी बैकग्राउंड मोड की ज़रूरत नहीं।

चरण 4: on-demand नियमों का सेट है, स्विच नहीं

isOnDemandEnabled केवल नियमों को तैयार करता है; NEOnDemandRuleConnect और उसके साथी तय करते हैं कि टनल कब ऊपर आए। probe URL वाला evaluate-connection नियम उसी URL जितना ही अच्छा है। अगर probe टनल के बिना जवाब देता है, तो नियम मान लेता है कि निजी नेटवर्क पहले से पहुँच योग्य है और कभी कनेक्ट नहीं होता, इसलिए इसे ऐसी चीज़ पर इंगित करें जो केवल अंदर से जवाब दे।

Always-on एक अलग वादा है। इसके लिए पर्यवेक्षित डिवाइस और प्रबंधित प्रोफ़ाइल चाहिए, और असुपरिवीक्षित उपयोगकर्ता प्रोफ़ाइल को जब चाहे हटा सकता है। ऐसा डिज़ाइन न भेजें जो always-on पर निर्भर हो, जब तक फ्लीट पर्यवेक्षित न हो।

चरण 5: लेबल नहीं, रास्ता साबित करें

tun, tap, ppp या ipsec इंटरफ़ेस खोजना यह साबित करता है कि VPN कॉन्फ़िगर है, यह नहीं कि आपके अनुरोध ने उसका उपयोग किया। usesInterfaceType(.other) के साथ NWPathMonitor कहता है कि वर्चुअल इंटरफ़ेस उपलब्ध है, और viability handler एक मेज़बान जाँच सकता है। इनमें से कोई भी निकास पथ साबित नहीं करता, इसलिए उन्हें ऐसे संसाधन के अनुरोध के साथ जोड़ें जहाँ केवल टनल पहुँच सके। इंटरफ़ेस नाम निदान के सहायक हैं, कभी ऐसा द्वार नहीं जिस पर ऐप्लिकेशन लॉजिक शाखा बनाए।

फ़ील्ड जाँच के लिए, टनल के साथ और बिना सार्वजनिक पता तुलना करें और केवल-आंतरिक पृष्ठ लाएँ। Status कॉल provider के बातचीत करते समय कनेक्टेड बता सकता है, इसलिए संसाधन के परिणाम को निर्णय करने दें और status को सहायक साक्ष्य मानें।

संबंधित लेख