NEVPNManager सुरक्षित गर्दैन? क्रम हो लोड, सक्षम, सुरक्षित, जडान
कोड 4 र कोड 5 ले सामान्यतया प्रोफाइल लोड हुनु अघि सम्पादन गरिएको वा अक्षम अवस्थामा सुरक्षित गरिएको जनाउँछ। कलको क्रम सुधार्नुहोस्, त्यसपछि entitlement जाँच्नुहोस्।
iOS मा Network Extension VPN का अधिकांश पहिलो प्रयासहरू दुई त्रुटि कोडले बुझाउँछन्: NEVPNErrorDomain Code=4 र Code=5। यीमध्ये कुनै पनि सर्भरको गुनासो होइन। एउटा तब देखिन्छ जब एपले डिस्कबाट कहिल्यै नपढिएको वस्तुमा सेटिङ लेख्छ, र अर्को तब जब लेखन आफै असफल हुन्छ, प्रायः प्रोफाइल अझै अक्षम हुँदा सुरक्षित गरिने भएकाले। दुवैलाई चार कलको क्रम बदलेर सुधारिन्छ, IKEv2 प्यारामिटर छोएर होइन।
पहिले लोड गर्नुहोस्, नत्र सुरक्षित गर्नसँग तुलना गर्न केही छैन
प्रबन्धकले सुरक्षित प्रोफाइलको प्रतिलिपि राख्छ, र तपाईंले सम्पादन गर्ने वस्तु त्यसलाई नपढेसम्म त्यो प्रतिलिपि होइन। पहिले loadFromPreferences कल गर्नुहोस्, त्यसको पूर्णता ह्यान्डलरभित्र सम्पादन गर्नुहोस्, त्यसपछि सुरक्षित गर्नुहोस्। पढाइ छोड्नुभयो भने, फ्रेमवर्कले आफूसँग भएको र तपाईंले लेखिरहेकोबीच बेमेल देख्छ। Swift मा प्रत्येक चरणको आकार एउटै हुन्छ, र प्रत्येक चरण आफ्नै क्लोजरमा पर्छ:
let mgr = NEVPNManager.shared()
mgr.loadFromPreferences { loadErr in
guard loadErr == nil else { return }
let proto = NEVPNProtocolIKEv2()
proto.serverAddress = "vpn.example.net"
proto.username = "alice"
proto.useExtendedAuthentication = true
mgr.protocolConfiguration = proto
mgr.isEnabled = true
mgr.saveToPreferences { saveErr in
// do not start here; reload, then connect
}
}
सुरक्षित क्लोजरभित्रबाट सुरुङ सुरु गर्नु अर्को ठाउँमा त्यही गल्ती हो। यो प्रोफाइल फेरि नपढिएसम्म चल्छ, त्यसैले सुरु गर्ने कलले तपाईंले बनाएको अवस्था देख्छ, सुरक्षित अवस्था होइन। सुरक्षित क्लोजर दोस्रो loadFromPreferences मा टुंगिन्छ, र त्यही पूर्णता ह्यान्डलरले मात्र startVPNTunnel कल गर्छ।
सक्षम गर्ने झन्डा सुरक्षित गर्नेको भाग हो
सुरक्षित प्रोफाइल अन नगरेसम्म निष्क्रिय हुन्छ। isEnabled = true त्यही लेखनमा सेट गर्नुहोस्, नत्र प्रोफाइल अक्षम रूपमा डिस्कमा पुग्छ र सेटिङले पूर्ण देखिने कन्फिगरेसन देखाए पनि startVPNTunnel अस्वीकार गर्छ।
बाह्य सम्पादन यसको अर्को आधा हो। प्रयोगकर्ताले सेटिङमा केही बदल्यो, वा उपकरण नेटवर्कबीच सर्यो भने, मेमोरीमा अझै राखिएका मानहरू विश्वास गर्नु अघि फेरि पढ्नुहोस्। वस्तुले ती परिवर्तन तपाईंका लागि अवलोकन गर्दैन। पुरानो प्रतिलिपि नै प्रयोगकर्ताको सम्पादन चुपचाप फर्काउने प्रोफाइल एपले लेख्ने बाटो हो। छेउछाउका दुई फिल्डले एउटै क्षणमा चुपचाप समस्या ल्याउँछन्: on-demand नियमहरू खाली प्लेसहोल्डर नभई नियम वस्तुहरूको एरे हुनुपर्छ, र disconnectOnSleep ले प्रतिलिपि गरिएको पूर्वनिर्धारित नभई तपाईंले छानेको व्यवहार प्रतिबिम्बित गर्नुपर्छ।
तेस्रो-पक्षका एपका लागि दुई प्रोटोकल मात्र उपलब्ध छन्
Network Extension ले एपहरूलाई IPsec र IKEv2 दिन्छ। L2TP र PPTP प्रणालीभित्रै रहन्छन्, त्यसैले तिनी चाहिने एपले ती पाउन सक्दैन, र यथार्थपरक उत्तर IKEv2 समर्थन गर्ने गेटवे वा व्यवस्थापित कन्फिगरेसन प्रोफाइल हो।
प्रमाणहरू पनि उही ढाँचा पछ्याउँछन्। पासवर्ड Keychain मा राख्नुहोस् र स्ट्रिङको सट्टा स्थायी सन्दर्भ दिनुहोस्। सुरक्षित गर्दा शून्य सन्दर्भले सामान्यतया वस्तु लेखिनु अघि नै खोजी चलेको जनाउँछ, प्रबन्धक बिग्रिएको होइन।
दुवै डिजाइन निर्णय हुन्, वैकल्पिक उपाय होइनन्। पासवर्ड आफ्नै प्राथमिकतामा राख्ने एपले फ्रेमवर्कले निरुत्साहित गर्ने बाटो छान्छ, र त्यसले निम्त्याउने असफलता सुरक्षित गर्ने त्रुटिजस्तो पढिन्छ।
कोड फेरि लेख्नु अघि entitlement बाहिर राख्नुहोस्
जब loadFromPreferences कत्ति पनि फर्केर कल गर्दैन, सम्भावित कारण हराएको Network Extension क्षमता वा त्यो नबोक्ने प्रोभिजनिङ प्रोफाइल हो। त्यो असफलता त्रुटि दिनुको सट्टा अड्किन्छ, र त्यसैले काम गर्ने कोड घण्टौं फेरि लेखिन्छ। तपाईं पठाउन चाहनुभएको हस्ताक्षरित बिल्डमा entitlement जाँच्नुहोस्, किनकि सिमुलेटरमा चलाउने र उपकरणमा चलाउने फरक हुन सक्छ र महत्त्वपूर्ण लक्ष्य उपकरण हो। लक्ष्यको हस्ताक्षर सेटिङ खोल्नुहोस् र ठ्याक्कै त्यही बिल्डका लागि Network Extension क्षमता छ भनी पुष्टि गर्नुहोस्।
entitlement नभएको प्रोभिजनिङ प्रोफाइल हार्डवेयरमा उही तरिकाले असफल हुन्छ, जबकि त्यही बिल्ड सिमुलेटरमा सामान्य रूपमा लोड हुन सक्छ। कलको क्रम फेरि लेख्नु अघि हस्ताक्षरित अभिलेख वास्तविक उपकरणमा परीक्षण गर्नुहोस्।
अनुमान होइन, अवस्थाका परिवर्तन हेर्नुहोस्
NEVPNStatusDidChangeNotification अवलोकन गर्नुहोस् र प्रत्येक चरणपछि manager.connection.status लग गर्नुहोस्। invalid कहिल्यै नछोड्ने अवस्थाले प्रोफाइल सुरक्षित नभएको वा entitlement नभएको जनाउँछ। connecting सम्म पुगेर कहिल्यै जडान नहुने जडानले प्रस्ताव वा प्रमाणतर्फ संकेत गर्छ, र त्यो फरक प्रमाणसहितको फरक अनुसन्धान हो।
प्रोफाइल सेटिङ, सामान्य, VPN मुनि देखिन्छ भनी पुष्टि गर्नुहोस् र प्रत्येक क्लोजरको त्रुटि लेख्नुहोस्। ती दुई तथ्यले अनुमानबिना क्रमको बग र अनुमतिको बग छुट्याउँछन्।