iOS VPN API: NEVPNManager, ടണൽ ദാതാവ് അല്ലെങ്കിൽ പ്രൊഫൈൽ?

മൂന്ന് വ്യത്യസ്ത ഉൽപ്പന്നങ്ങൾ 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-നെ പിന്തുണയ്ക്കുന്ന തെളിവായി കണക്കാക്കുക.