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 लाई सहायक प्रमाण मान्नुहोस्।

सम्बन्धित लेखहरू