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 मदत करू शकत नाही: तिसऱ्या पक्षाच्या प्रोटोकॉलसाठी त्याला हुक नाही। त्या प्रकरणासाठी प्रोटोकॉल अंमलात आणणाऱ्या packet tunnel provider सह NETunnelProviderManager आवश्यक आहे। प्रोफाइल फक्त कॉन्फिगरेशन वितरित करते आणि ऑपरेटिंग सिस्टमकडे नसलेला ट्रान्सपोर्ट ते जोडू शकत नाही।

PPTP सध्याच्या प्रणालींवर लक्ष्य नाही। Shared-secret IPsec अजूनही remoteIdentifier मधील गटाचे नाव, गुप्तता ठेवणारी keychain वस्तू आणि सर्व्हरने वापरकर्तानाव मागितल्यावर विस्तारित प्रमाणीकरणाची अपेक्षा करते। प्रत्येक गहाळ तुकडा त्याच सामान्य कॉन्फिगरेशन त्रुटीने दिसतो, म्हणून दुसरे काही डीबग करण्यापूर्वी ते सर्व जोडा।

पायरी 2: जतन, लोड, प्रारंभ या क्रमाचे पालन करा

NEVPNManager preferences मध्ये लिहिते, ते परत वाचते आणि त्यानंतरच सुरू करते। प्रोटोकॉल आणि manager ऑब्जेक्ट भरा, saveToPreferences कॉल करा, loadFromPreferences कॉल करा आणि load completion handler मधून startVPNTunnel कॉल करा। लोड परत येण्यापूर्वी सुरू केल्यास अन्यथा बरोबर असलेल्या कॉन्फिगरेशनवर configuration-invalid त्रुटी, NEVPNErrorDomain code 1 येते।

आकार एकाच ठिकाणी ठेवण्याइतका लहान आहे:

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

startVPNTunnel विनंती स्वीकारल्यावर परत येते, टनेल वर आल्यावर नाही। NEVPNStatusDidChange पहा आणि खऱ्या स्थितीसाठी connection.status वाचा। कॉलच्या ठिकाणी यश गृहीत धरणारे ॲप extension अजून वाटाघाटी करत असतानाच VPN कनेक्टेड असल्याचे सांगते। Connecting स्थिती क्षणभरासाठी सामान्य आहे; ती कधीही न सोडणारी स्थिती हीच नोंद करण्यायोग्य अयशस्वीता।

पायरी 3: provider प्रक्रियेला आवश्यक ते द्या

Custom transport स्वतःच्या bundle identifier आणि स्वतःच्या entitlement सह वेगळ्या प्रक्रियेत चालते। container ॲप आणि provider दोघांनाही स्वाक्षरीच्या वेळी network-extension entitlement आवश्यक असते, आणि App Store बाहेरील Developer ID build लाही ते provisioning profile मध्ये ठेवावे लागते। गहाळ entitlement प्रोटोकॉल बगसारखे वाटते कारण extension सुरू होतच नाही।

उधार घेण्यासाठी सार्वजनिक socket descriptor नाही। NEPacketTunnelProvider तुम्हाला read, write आणि cancel सह NEPacketTunnelFlow देते, आणि खाजगी की मार्गांकडे जाणारा कोड आवृत्त्यांमध्ये तुटतो। ॲप background मध्ये असतानाही provider चालू राहते, म्हणून container ॲपला त्यासाठी background मोडची गरज नाही।

पायरी 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 एक होस्ट तपासू शकतो। दोन्हीपैकी कोणतेही बाहेर पडण्याचा मार्ग सिद्ध करत नाही, म्हणून ते केवळ टनेल पोहोचू शकेल अशा संसाधनाकडील विनंतीशी जोडा। इंटरफेस नावे निदानासाठी मदत आहेत, ॲप्लिकेशन लॉजिकने फांदी काढावी असे प्रवेशद्वार कधीही नाही।

क्षेत्रीय तपासणीसाठी, सार्वजनिक पत्ता टनेलसह आणि त्याशिवाय तुलना करा आणि केवळ-अंतर्गत पृष्ठ आणा। provider वाटाघाटी करत असताना status कॉल कनेक्टेड सांगू शकतो, म्हणून संसाधनाच्या निकालालाच निर्णय घेऊ द्या आणि status ला पूरक पुरावा माना।

संबंधित लेख