NEVPNManager iOS पर क्या बना सकता है (और क्या नहीं)
iOS का VPN API तीन प्रोटोकॉल क्लासों से ऐप के स्वामित्व वाला एक कॉन्फ़िगरेशन बनाता है। L2TP, PPTP और हस्ताक्षरित प्रोफ़ाइल उस सतह का हिस्सा नहीं हैं।
जब आप iOS ऐप के अंदर VPN स्क्रीन बनाते हैं, तो पहला आश्चर्य यह है: Settings ऐप की प्रोटोकॉल सूची API की सूची नहीं है। Network Extension फ़्रेमवर्क आपके ऐप को एक व्यक्तिगत VPN कॉन्फ़िगरेशन बनाने देता है, जो उसी ऐप का होता है, और यह केवल कुछ प्रोटोकॉल ऑब्जेक्ट स्वीकार करता है। लोग जो और कुछ अपेक्षा करते हैं, L2TP से लेकर डाउनलोड किए गए प्रोफ़ाइल तक, उस सतह से बाहर है या Apple के लिए निजी है। आगे आने वाली विफलताएँ आम तौर पर बग नहीं होतीं, वे API का ऐसे काम से इंकार हैं जो उसे कभी दिया ही नहीं गया।
मिथक: API एक Settings संपादक है
माना जाता है कि चूँकि iOS IKEv1, IKEv2, L2TP और IPsec प्रोफ़ाइल कॉन्फ़िगर कर सकता है, कोई ऐप उनमें से कोई भी प्रोग्रामेटिक रूप से बना सकता है। ऐसा नहीं है। फ़्रेमवर्क कॉल करने वाले ऐप को ठीक एक कॉन्फ़िगरेशन स्लॉट देता है, और वह स्लॉट केवल सार्वजनिक प्रोटोकॉल क्लासों का एक छोटा समूह स्वीकार करता है। लोग जो और कुछ अपेक्षा करते हैं, L2TP से लेकर डाउनलोड किए गए प्रोफ़ाइल तक, उस सतह से बाहर है या Apple के लिए निजी है।
आगे आने वाली विफलताएँ आम तौर पर बग नहीं होतीं। वे API का ऐसे काम से इंकार हैं जो उसे कभी दिया ही नहीं गया, और समाधान यह है कि स्क्रीन को उसी के इर्द-गिर्द डिज़ाइन करें जिसका स्वामित्व API के पास है।
तीन प्रोटोकॉल ऑब्जेक्ट और वे जो मौजूद नहीं हैं
आपके विकल्प हैं IKEv1 NEVPNProtocolIPSec के ज़रिए, IKEv2 NEVPNProtocolIKEv2 के ज़रिए, और NETunnelProviderProtocol यदि आप अपना पैकेट टनल एक्सटेंशन भेजते हैं। NEVPNManager संदर्भ स्वीकृत प्रोटोकॉल ऑब्जेक्ट की सूची देता है। L2TP और PPTP उस सूची में कभी नहीं आते क्योंकि Apple ने उनके लिए कोई क्लास प्रकाशित नहीं की। इनमें से किसी को भी आज़माना सहेजने के समय त्रुटि पर समाप्त होता है, या और बुरा, ऐसे कॉन्फ़िगरेशन पर जिसे सिस्टम चुपचाप उपयोग करने से इंकार कर देता है।
डेस्कटॉप कोड अलग नियमों का पालन करता है। macOS पर, SCNetworkInterfaceCreateWithInterface IPv4 पर L2TP जैसे इंटरफ़ेस प्रकार को स्टैक करता है और उसे नेटवर्क सेवा से जोड़ता है, और networksetup -connectpppoeservice परिणाम शुरू करता है। एडमिनिस्ट्रेटर अधिकार और सहायक उपकरण आवश्यक हैं, क्योंकि साझा रहस्य और पासवर्ड सिस्टम कीचेन में जाते हैं। उस डिज़ाइन को iOS पर कॉपी करें और कुछ भी कंपाइल नहीं होगा।
पासवर्ड नहीं, कीचेन संदर्भ दें
कोई भी IKE क्लास पासवर्ड को टेक्स्ट के रूप में स्वीकार नहीं करती। दो प्रॉपर्टी passwordReference और sharedSecretReference एक स्थायी कीचेन संदर्भ चाहती हैं, जो आप SecItemCopyMatching से kSecReturnPersistentRef माँगकर प्राप्त करते हैं। आइटम डेटा पास करना, या फ़ील्ड में स्ट्रिंग डालना, सहेजने में विफलता या खाली क्रेडेंशियल वाला कनेक्शन पैदा करता है। संदर्भ उतना ही टिकाऊ है जितना उसके पीछे का कीचेन आइटम, इसलिए आइटम को कॉन्फ़िगरेशन जुड़ने से पहले मौजूद होना चाहिए। इसे सहेजने के उसी लेन-देन में बनाएँ और आप क्रम-संबंधी बग की पूरी श्रेणी हटा देते हैं।
प्रमाणपत्र प्रमाणीकरण अलग रास्ता लेता है: PKCS#12 ब्लॉब के लिए identityData और identityDataPassword। उस ब्लॉब को ऐप बंडल के अंदर भेजना नमूना कोड से आई आदत है, न कि रिलीज़ का निर्णय, क्योंकि पासवर्ड उसके साथ यात्रा करता है और ऐप की हर प्रति वही पहचान लेकर चलती है।
अधिकार और उपलब्धता सब कुछ तय करते हैं
हो सकता है कि मैनेजर बिल्कुल मौजूद ही न हो, और कारण प्रोविज़निंग है। आपके ऐप पहचानकर्ता को Network Extension क्षमता के साथ व्यक्तिगत VPN अधिकार चाहिए, और बिल्ड पर हस्ताक्षर करने वाली प्रोफ़ाइल में दोनों होने चाहिए।
इसे छोड़ दें तो साझा इंस्टेंस nil लौटाता है, या सहेजना ऐसी त्रुटि से विफल होता है जो अधिकार का कभी उल्लेख नहीं करती। उपलब्धता दूसरा द्वार है। iOS 8 से पुराने किसी लक्ष्य पर रनटाइम में सिंबल गायब रहता है, इसलिए विफलता क्रैश या nil मैनेजर है, बिना कॉन्फ़िगरेशन वाला मैनेजर नहीं। अपने ऑब्जेक्ट ग्राफ़ को डीबग करने से पहले रनटाइम और अधिकार जाँचें।
लोड करें, बदलें, सहेजें, फिर माँग पर आधारित क्रम देखें
जीवनचक्र को लोड, बदलाव, सहेजना मानें और लोड कभी न छोड़ें। जब तक loadFromPreferences पूरा नहीं होता, मैनेजर कुछ नहीं रखता और प्रोटोकॉल ऑब्जेक्ट को पढ़ा या बदला नहीं जा सकता।
दूसरा सहेजना कॉन्फ़िगरेशन को बदल देता है, दूसरा जोड़ने के बजाय, इसलिए अधूरा सहेजना काम कर रहे प्रोफ़ाइल को नुकसान पहुँचा सकता है। माँग पर आधारित नियम एक क्रमित सरणी बनाते हैं, और वही क्रम नीति है। कहीं-से-भी-कनेक्ट नियम को डिस्कनेक्ट नियम से पहले रखें और मैनुअल डिस्कनेक्ट के बाद तुरंत फिर से कनेक्ट होता है, जो दोष जैसा लगता है पर दस्तावेज़ित मूल्यांकन का पालन करता है।
जब उपयोगकर्ता की क्रिया को जीतना हो तो डिस्कनेक्ट नियम को आगे लाएँ। ऐप के नियंत्रण से बाहर जो रहता है वह भी उतना ही मायने रखता है। रूट टनल या सर्वर नीति से आते हैं, आपकी सेट की गई प्राथमिकता से नहीं, और पैकेट टनल प्रदाता शुरू होने पर उनकी रिपोर्ट करता है। ऐप दूसरे ऐप्स या कॉन्फ़िगरेशन प्रोफ़ाइल द्वारा इंस्टॉल किए गए प्रोफ़ाइल को सूचीबद्ध या संपादित नहीं कर सकता, इसलिए ऐसी स्क्रीन का वादा न करें जो डिवाइस का हर VPN दिखाए।