ടണൽ പ്രവർത്തിക്കുമ്പോൾ നിങ്ങളുടെ iOS VPN ആപ്പ് വിച്ഛേദിച്ചതായി കാണിക്കുന്നത് എന്തുകൊണ്ട്

നിങ്ങളുടെ ആപ്പ് വിച്ഛേദിച്ചതായി പറയുന്നു, മെനു ബാർ കണക്ട് ചെയ്തതായി പറയുന്നു, ട്രാഫിക് വ്യക്തമായി ഒഴുകുന്നു. ആ വിടവ് വീണ്ടും ശ്രമിച്ച് പരിഹരിക്കാവുന്ന ഒരു റേസ് കണ്ടീഷൻ അല്ല: ആപ്പും ടണലും വെവ്വേറെ പ്രോസസുകളാണ്, നിങ്ങളുടെ കോഡ് വായിക്കുന്ന ഒബ്ജക്റ്റ് സിസ്റ്റം സൂക്ഷിക്കുന്ന കോൺഫിഗറേഷന്റെ കാഷെ ചെയ്ത കാഴ്ചയാണ്. Apple-ന്റെ Personal VPN ഉപരിതലം ഒരു നിയന്ത്രണ API ആണ്, ഡാറ്റ പാതയല്ല, അതിന്റെ വിചിത്ര സ്വഭാവത്തിന്റെ ഭൂരിഭാഗവും ആ ഒരു വസ്തുതയിൽ നിന്നാണ് വരുന്നത്. ഓരോ കോളിലും യഥാർത്ഥത്തിൽ എന്ത് സംഭവിക്കുന്നു എന്നത് ഇതാ.

മാനേജർ ഒബ്ജക്റ്റ് ഒരു കാഷെ ചെയ്ത കാഴ്ചയാണ്, ടണലല്ല

NETunnelProviderManager സിസ്റ്റത്തിന്റെ ഉടമസ്ഥതയിലുള്ള ഒരു മുൻഗണന സ്റ്റോറിൽ നിന്ന് നിറയ്ക്കുന്നു, അതിനാൽ loadFromPreferences പൂർത്തിയാകുന്നതുവരെ അതിന്റെ ഗുണങ്ങൾക്ക് ഒരർത്ഥവുമില്ല. അതിന് മുൻപ് connection.status വായിച്ചാൽ നിങ്ങൾക്ക് ഒരു സ്ഥിരസ്ഥിതി മൂല്യം ലഭിക്കും, അതുകൊണ്ടാണ് പുനരാരംഭത്തിന് ശേഷമുള്ള ആദ്യ സ്ഥിതി പുതുക്കൽ ടണൽ പ്രവർത്തിക്കുമ്പോഴും വിച്ഛേദിച്ചതായി റിപ്പോർട്ട് ചെയ്യുന്നത്. ആദ്യം ലോഡ് ചെയ്യുക, തുടർന്ന് അതേ പൂർത്തീകരണ ഹാൻഡ്ലറിൽ നിന്ന് സ്ഥിതിയും പ്രോട്ടോക്കോൾ കോൺഫിഗറേഷനും വായിക്കുക. പിന്നീടുള്ള മാറ്റങ്ങൾ പോളിംഗിന് പകരം NEVPNStatusDidChange വഴി നിരീക്ഷിക്കുക, കൂടാതെ On Demand ആരംഭിച്ച കണക്ഷനുകൾക്കും അറിയിപ്പ് പ്രവർത്തിക്കുന്നു എന്ന് ശ്രദ്ധിക്കുക, അവിടെ എന്തെങ്കിലും തിരികെ നൽകാൻ ഒരു ആപ്പ് കോളും ഇല്ല. പ്രോട്ടോക്കോൾ ക്രമീകരണങ്ങൾക്കും ഇതുതന്നെ ബാധകമാണ്: അവ ലോഡ് ചെയ്ത കോൺഫിഗറേഷനിൽ നിന്ന് വായിക്കുന്നു, ആപ്പ് കൈമാറിയതിൽ നിന്നല്ല.

ടണൽ തന്നെ Network Extension ദാതാവിന്റെ പ്രോസസിൽ ജീവിക്കുന്നു, അതിനാൽ ആപ്പിന് കണക്ഷൻ നഷ്ടപ്പെടുത്താതെ സ്വന്തം അവസ്ഥ നഷ്ടപ്പെടാം. ഇന്റർഫേസ് കാണിക്കുന്നതെല്ലാം മാനേജരിൽ നിന്ന് പുനർനിർമ്മിക്കണം, കഴിഞ്ഞ സെഷനിൽ നിന്ന് ഓർത്തുവയ്ക്കരുത്.

ആരംഭ ക്രമം: സേവ് ചെയ്യുക, ലോഡ് ചെയ്യുക, പിന്നീട് ആരംഭിക്കുക

ദാതാവ് അടിസ്ഥാനമാക്കിയ കണക്ഷന് ക്രമത്തിൽ മൂന്ന് ഘട്ടങ്ങൾ വേണം. ദാതാവിന്റെ കോൺഫിഗറേഷൻ എഴുതി saveToPreferences വിളിക്കുക, സേവ് ചെയ്ത കോൺഫിഗറേഷൻ നിങ്ങളുടെ കൈവശമുള്ളതായിരിക്കാൻ മാനേജർ ലോഡ് ചെയ്യുക, തുടർന്ന് NETunnelProviderSession.startVPNTunnel() വഴി ആരംഭിക്കുക. സേവ് ഒഴിവാക്കിയാൽ ആരംഭത്തിന് ആരംഭിക്കാൻ ഒന്നുമില്ല; സേവിന് മുൻപ് ലോഡ് ചെയ്താൽ മാനേജർ ഇപ്പോഴും പഴയ കോൺഫിഗറേഷൻ പ്രതിഫലിപ്പിക്കുന്നു.

startVPNTunnel തിരികെ നൽകുന്ന ബൂളിയൻ അഭ്യർത്ഥന സ്വീകരിച്ചു എന്ന് മാത്രം പറയുന്നു. ദാതാവ് തലത്തിലുള്ള പരാജയങ്ങൾ പിന്നീട് വിച്ഛേദിത അവസ്ഥയിലേക്കുള്ള മാറ്റമായി വരുന്നു, അത് നിങ്ങൾ NEVPNStatusDidChange അറിയിപ്പിലൂടെ നിരീക്ഷിക്കുന്നു, കൂടാതെ അറിയിപ്പ് ഹാൻഡ്ലർ loadFromPreferences ന് ശേഷം connection.status വീണ്ടും വായിക്കണം, കാരണം കാഷെ ചെയ്ത മൂല്യം ഇപ്പോഴും പഴയതായിരിക്കാം. അഭ്യർത്ഥന തലത്തിലുള്ള പരാജയങ്ങൾ കോളിന്റെ എക്സെപ്ഷൻ എറിയുന്ന രൂപത്തിൽ നിന്ന് ഉടനടി തിരികെ വരുന്നു, അല്ലെങ്കിൽ startVPNTunnelAndReturnError: ന്റെ പിശക് ഔട്ട്പുട്ട് പാരാമീറ്റർ വഴി. തിരികെ നൽകുന്ന മൂല്യത്തെ ഫലമായി കണക്കാക്കുന്ന കോഡ് ഒരിക്കലും സ്ഥാപിക്കപ്പെടാത്ത ഒരു കണക്ഷൻ റിപ്പോർട്ട് ചെയ്യുന്നു. മറ്റൊരു നിശബ്ദ പരാജയം ഇൻസ്റ്റാൾ ചെയ്ത എക്സ്റ്റൻഷനുമായി പൊരുത്തപ്പെടാത്ത ദാതാവ് ബണ്ടിൽ ഐഡന്റിഫയർ ആണ്: അഭ്യർത്ഥന നിരസിക്കപ്പെടുന്നു, സന്ദേശത്തിൽ ഒന്നും ഐഡന്റിഫയറിലേക്ക് ചൂണ്ടുന്നില്ല. ഐഡന്റിഫയർ തെറ്റാണെങ്കിൽ അഭ്യർത്ഥന സാധാരണയായി ഉടനടി പരാജയപ്പെടുന്നു, ദാതാവിന്റെ ഒരു ലോഗ് വരി പോലും വരുന്നതിന് മുൻപ്.

ആരംഭത്തിന് ശേഷം മുൻഗണനകൾ വീണ്ടും ലോഡ് ചെയ്യുന്നതാണ് സ്ഥിതി സ്ക്രീനുകളെ ശരിയാക്കുന്നത്. സിസ്റ്റം കോൺഫിഗറേഷൻ മാറ്റുമ്പോൾ മാനേജർ നിങ്ങളിലേക്ക് പുതിയ കോൺഫിഗറേഷൻ തള്ളുന്നില്ല.

വിശ്വാസ വസ്തു പ്രൊഫൈലിലൂടെ വരുന്നു, ഒരിക്കലും ആപ്പ് കോഡിൽ നിന്നല്ല

iOS വിശ്വാസ സ്റ്റോറിലേക്ക് റൂട്ട് സർട്ടിഫിക്കറ്റ് ചേർക്കാൻ ആപ്പിന് പിന്തുണയ്ക്കുന്ന വഴിയില്ല, അതിനാൽ Personal VPN കോൺഫിഗറേഷന് ഉപകരണം ഇതിനകം വിശ്വസിക്കുന്ന വസ്തുവിനെ മാത്രമേ റഫർ ചെയ്യാൻ കഴിയൂ: ഇൻസ്റ്റാൾ ചെയ്ത പ്രൊഫൈൽ, ഉപകരണ മാനേജ്മെന്റ് അല്ലെങ്കിൽ സിസ്റ്റം മറ്റ് കാരണങ്ങളാൽ വിശ്വസിക്കുന്ന ഒരു CA സ്ഥാപിച്ച ശൃംഖല. ആദ്യ പ്രവർത്തനത്തിൽ സ്വന്തം CA നിർമ്മിച്ച് സിസ്റ്റം അത് അംഗീകരിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്ന ആപ്പ് ദാതാവിനുള്ളിലെ സാധുതാ പരിശോധനയിൽ പരാജയപ്പെടും, അവിടെ ആപ്പിന്റെ ഇന്റർഫേസിന് കാരണം കാണാൻ കഴിയില്ല.

ആ അതിർത്തിയെ അത് ഇരിക്കുന്ന രീതിയിൽ ഡിസൈൻ നിയന്ത്രണമായി കാണുക, എൻറോൾമെന്റ് പ്രൊഫൈലിനൊപ്പം വിശ്വാസ ആങ്കർ അയയ്ക്കുക. VPN പ്രാമാണീകരണം വിശ്വാസ തീരുമാനത്തിൽ നിന്ന് വേർതിരിച്ച് നിർത്തുക, കാരണം അവ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പരാജയപ്പെടുന്നു, വ്യത്യസ്ത ആളുകളാണ് അവ ഡീബഗ് ചെയ്യുന്നത്.

കൗണ്ടറുകൾ ഇന്റർഫേസിൽ നിന്ന് വരുന്നു, VPN API യിൽ നിന്നല്ല

മാനേജർ സ്ഥിതിയും കോൺഫിഗറേഷനും വെളിപ്പെടുത്തുന്നു, ഓരോ ടണലിനും ബൈറ്റുകൾ എണ്ണുന്ന ഒന്നുമില്ല. ഉപയോഗ കണക്കുകൾ വേണമെങ്കിൽ getifaddrs() വിളിച്ച് ബന്ധപ്പെട്ട ഇന്റർഫേസിനായി if_data വായിക്കുക: Wi-Fi-ന് en0, സെല്ലുലാറിന് pdp_ip ഇന്റർഫേസുകൾ, ടണലിന് തന്നെ utun ഉപകരണം. utun കൗണ്ടറുകൾ ആന്തരിക ട്രാഫിക് വിവരിക്കുന്നു, പ്രോട്ടോക്കോൾ ഓവർഹെഡ് ഉൾപ്പെടുന്നു.

ഈ കണക്കുകൾ കണക്കുകൂട്ടലുകളാണ്, ആപ്പ് തിരിച്ചുള്ള അക്കൗണ്ടിംഗല്ല, ഇന്റർഫേസ് വീണ്ടും സൃഷ്ടിക്കുമ്പോൾ അവ പുനഃസജ്ജീകരിക്കുന്നു. ഇന്റർഫേസിൽ അവ അങ്ങനെ ലേബൽ ചെയ്യുക, അല്ലാത്തപക്ഷം ആരെങ്കിലും അവ ഉപയോഗിച്ച് ഉപഭോക്താവിന് ബിൽ ചെയ്യും. ആപ്പ് തിരിച്ചുള്ള കണക്കുകൾ വേണമെങ്കിൽ തികച്ചും വ്യത്യസ്തമായ ഒരു സംവിധാനം വേണം, ഈ ഫീൽഡുകളുടെ മികച്ച വായനയല്ല.

വൃത്തിയാക്കൽ stopVPNTunnel-ൽ ആണ്, അവസാനിപ്പിക്കലിലല്ല

applicationWillTerminate സിസ്റ്റം പ്രോസസ് കൊല്ലുന്നതിന് മുൻപ് നിങ്ങൾക്ക് കുറച്ച് സെക്കൻഡുകൾ നൽകുന്നു, അത് കണക്ഷൻ പൊളിക്കാൻ വിശ്വസനീയമായ സ്ഥലമല്ല. സ്റ്റോപ്പ് stopVPNTunnel() ലേക്ക് അയയ്ക്കുക അല്ലെങ്കിൽ ദാതാവിന്റെ സ്റ്റോപ്പ് കോൾബാക്കിൽ കൈകാര്യം ചെയ്യുക, നിങ്ങൾ ആരംഭിച്ച മാനേജർ അല്ലെങ്കിൽ കോൺഫിഗറേഷൻ ഐഡന്റിഫയർ സൂക്ഷിക്കുക, അതുവഴി സ്റ്റോപ്പ് ഉപകരണത്തിലെ ഓരോ കോൺഫിഗറേഷനെയല്ല, ആ കണക്ഷനെ ലക്ഷ്യമിടും.

ആ ഐഡന്റിഫയർ അതിന്റെ പ്രൊഫൈലിനൊപ്പം സൂക്ഷിക്കുക, കാരണം മാനേജർ ഒബ്ജക്റ്റ് ഉപയോക്താവ് ഏത് കോൺഫിഗറേഷൻ തിരഞ്ഞെടുത്തു എന്ന് രേഖപ്പെടുത്തുന്നില്ല. On Demand ഉയർത്തുന്ന കണക്ഷന്റെ പിന്നിൽ ഒരു ആപ്പ് കോളും ഇല്ല എന്ന് ഓർക്കുക, അതിനാൽ സ്ഥിതി സ്ക്രീൻ എന്തെങ്കിലും വരയ്ക്കുന്നതിന് മുൻപ് ഇപ്പോഴും മുൻഗണനകൾ ലോഡ് ചെയ്യണം.