NEVPNManager जतन करत नाही? क्रम आहे लोड, सक्षम, जतन, कनेक्ट

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 अंतर्गत दिसते याची खात्री करा आणि प्रत्येक क्लोजरची त्रुटी नोंदवा। ती दोन तथ्ये अंदाजाशिवाय क्रमातील बग आणि परवानगीची बग वेगळी करतात।