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 എന്നിവയ്ക്ക് കീഴിൽ കാണുന്നുവെന്ന് ഉറപ്പാക്കുക, ഓരോ ക്ലോസറിന്റെയും പിശക് രേഖപ്പെടുത്തുക. ആ രണ്ട് വസ്തുതകൾ അനുമാനമില്ലാതെ ക്രമ പിശകിനെ അനുമതി പിശകിൽ നിന്ന് വേർതിരിക്കുന്നു.