Android 12 IKEv1 VPN: ലോഞ്ച് പതിപ്പ്, IKEv2, തേർഡ്-പാർട്ടി ആപ്പുകൾ

രണ്ട് ഫോണുകളും സെറ്റിംഗ്സിൽ Android 12 കാണിക്കുന്നു, എന്നാൽ അവയിൽ ഒന്ന് മാത്രമാണ് നിങ്ങളുടെ ഗേറ്റ്വേ നൽകുന്ന പഴയ IPsec XAuth പ്രൊഫൈൽ ഇപ്പോഴും ആരംഭിക്കുന്നത്. വ്യത്യാസം ഉപഭോക്താവിന് എത്താവുന്ന ഒരു ക്രമീകരണമല്ല: നേറ്റീവ് ലെഗസി IKEv1 പാതയെ നിയന്ത്രിക്കുന്ന ഗാർഡ്, ഉപകരണം വിതരണം ചെയ്ത SDK ലെവൽ നോക്കുന്നു, അത് ഇപ്പോൾ പ്രവർത്തിക്കുന്ന റിലീസ് മാത്രമല്ല. ആ ഒറ്റ വിശദാംശം ഫ്ലീറ്റ് താരതമ്യം അർത്ഥവത്താണോ എന്ന് തീരുമാനിക്കുന്നു, കൂടാതെ മൂന്ന് മൈഗ്രേഷൻ പാതകളിൽ ഏതാണ് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ വേണ്ടത് എന്നും അത് തീരുമാനിക്കുന്നു.

രണ്ട് Android 12 ഫോണുകൾ ഒരേ ടെസ്റ്റ് കേസല്ല

പുതിയ ഉപകരണങ്ങൾ ലെഗസി IKEv1 പ്രൊഫൈലുകൾ ആരംഭിക്കുന്നത് നിർത്തിയ AOSP മാറ്റം DEVICE_INITIAL_SDK_INT Android S-മായി താരതമ്യം ചെയ്യുന്നു, അതായത് API 31. നേറ്റീവ് ലെഗസി സ്റ്റാർട്ടപ്പ് പാതയിൽ, യോഗ്യമായ ഒരു പ്രൊഫൈൽ ഉപയോഗപ്രദമായ കണക്ഷൻ ഉണ്ടാകുന്നതിന് മുമ്പുതന്നെ പിന്തുണയ്ക്കാത്ത പ്രവർത്തന പരാജയം ഉയർത്തുന്നു. Android 11-ൽ വിതരണം ചെയ്ത് പിന്നീട് അപ്ഡേറ്റ് ചെയ്ത ഫോൺ ആ ഗാർഡ് ഇപ്പോഴും കടക്കുന്നു; Android 12-ൽ ലോഞ്ച് ചെയ്ത മോഡൽ കടക്കുന്നില്ല.

ഡീബഗ്ഗിംഗ് പ്രവർത്തനക്ഷമമാക്കിയ ഉപകരണത്തിൽ രണ്ട് സംഖ്യകളും വായിക്കാം:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

ആദ്യ മൂല്യം ഗാർഡിന് പ്രധാനമായ ലോഞ്ച് ലെവൽ ആണ്, രണ്ടാമത്തേത് ഫോൺ ഇന്ന് പ്രവർത്തിപ്പിക്കുന്നത്. പ്രോപ്പർട്ടി ഇല്ലാത്തിടത്ത്, മാർക്കറ്റിംഗ് പേരിൽ നിന്ന് ഊഹിക്കുന്നതിനുപകരം മോഡൽ പിന്തുണാ ഡോക്യുമെന്റേഷനെ ആശ്രയിക്കുക, കൂടാതെ വെണ്ടർ ബിൽഡ് അതിന്റെ അടിസ്ഥാന റിലീസിനുണ്ടായിരുന്ന എല്ലാ അനുയോജ്യതാ പാതകളും സംരക്ഷിക്കുന്നു എന്ന് അനുമാനിക്കരുത്.

ഒരു കൂടുതൽ വ്യത്യാസം ഒരു മണിക്കൂർ പാഴായ സപ്പോർട്ട് സമയം ലാഭിക്കുന്നു: VPN സെറ്റിംഗ്സിൽ ഇപ്പോഴും ലിസ്റ്റ് ചെയ്തിരിക്കുന്ന സേവ് ചെയ്ത പ്രൊഫൈൽ, പ്ലാറ്റ്ഫോം അത് ആരംഭിക്കുമോ എന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. PSK വീണ്ടും നൽകുന്നതോ റൂട്ടുകൾ എഡിറ്റ് ചെയ്യുന്നതോ നേരത്തെ പ്രവർത്തിക്കുന്ന പ്രോട്ടോക്കോൾ പിന്തുണാ പരിശോധന നീക്കാൻ കഴിയില്ല, കൂടാതെ ആ പരാജയം ക്രെഡൻഷ്യൽ പ്രശ്നമല്ലാതിരിക്കെ ക്രെഡൻഷ്യൽ പ്രശ്നം പോലെ തോന്നുന്നു.

പാത ഒന്ന്: നേറ്റീവ് ലെഗസി സ്റ്റാക്ക് ഇപ്പോഴും പ്രവർത്തിക്കുന്നിടത്ത് നിലനിർത്തുക

സിസ്റ്റം VPN സ്ക്രീനിൽ നിന്ന് IPsec XAuth PSK, IPsec Hybrid RSA, L2TP/IPsec PSK പ്രൊഫൈലുകൾ വായിക്കുന്നത് ലെഗസി സ്റ്റാക്ക് ആണ്. API 31-ന് താഴെ വിതരണം ചെയ്ത ഉപകരണത്തിൽ അപ്ഗ്രേഡിന് ശേഷവും അത് സാധ്യമായ പാതയായി തുടരുന്നു, അതിനാലാണ് പഴയ ഹാൻഡ്സെറ്റിലെ പൈലറ്റ് വിജയിക്കുകയും പുതിയ ഹാൻഡ്സെറ്റ് അതേ പ്രൊഫൈൽ നിരസിക്കുകയും ചെയ്യുന്നത്.

പ്രധാന താരതമ്യം Android പതിപ്പനുസരിച്ചല്ല, ഉപകരണ ക്ലാസ് അനുസരിച്ചാണ്: ഫ്ലീറ്റിലെ മോഡലുകൾ ലിസ്റ്റ് ചെയ്യുക, അവയുടെ ലോഞ്ച് API ലെവലുകൾ വായിക്കുക, പ്രൊഫൈൽ ഇപ്പോഴും ആരംഭിക്കുന്ന ഉപകരണങ്ങളും കഴിയാത്ത ഉപകരണങ്ങളും ആയി അവയെ വിഭജിക്കുക. മറ്റെല്ലാം ഒരു ഉപഭോക്താവ് പുതിയ ഫോൺ വാങ്ങുന്ന നിമിഷം സ്വയം വിരുദ്ധമാകുന്ന ഒരു സപ്പോർട്ട് നയം സൃഷ്ടിക്കുന്നു.

പാത രണ്ട്: പ്ലാറ്റ്ഫോം IKEv2 പ്രൊഫൈലുകൾ

IKEv2-നുള്ള Android-ന്റെ പൊതു പ്രൊവിഷനിംഗ് മോഡൽ വേറൊരു ഒബ്ജക്റ്റാണ്, പേരുമാറ്റിയ IKEv1 പ്രൊഫൈലല്ല. IKEv2 പ്രൊഫൈലുകൾക്കുള്ള പ്ലാറ്റ്ഫോം API API 30-നൊപ്പം വന്നു, ഗേറ്റ്വേ നൽകുന്ന ഓതന്റിക്കേഷൻ രീതിയോടുകൂടിയ IKEv2 പ്രതീക്ഷിക്കുന്നു, സാധാരണയായി സർട്ടിഫിക്കറ്റ് അടിസ്ഥാനമാക്കിയതോ EAP-യോ. IKEv1 XAuth അല്ലെങ്കിൽ Hybrid-ൽ നിന്ന് IKEv2-ലേക്ക് വയർ-അനുയോജ്യമായ അപ്ഗ്രേഡ് ഇല്ല: പുതിയ പ്രോട്ടോക്കോളിനായി ഗേറ്റ്വേ കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്, പ്രൊഫൈലിൽ യോജിക്കുന്ന ഐഡന്റിറ്റി ഉണ്ടായിരിക്കണം.

ഏറ്റവും ദൈർഘ്യമേറിയ ആയുസ്സുള്ള പാതയാണിത്, യഥാർത്ഥ ജോലി വെളിപ്പെടുത്തുന്നതും ഇതുതന്നെ. ഐഡന്റിറ്റി വാലിഡേഷൻ, ഉപയോക്തൃ ഓതന്റിക്കേഷൻ, DNS, സ്പ്ലിറ്റ്-ടണൽ റൂട്ടുകൾ, റിസോഴ്സ് അധികാരപ്പെടുത്തൽ എന്നിവയെല്ലാം മൈഗ്രേഷനെ അതിജീവിക്കണം; ഹാൻഡ്ഷേക്ക് മാത്രം വിജയിച്ചാൽ ഉപയോക്താക്കൾ ഒന്നും എത്താത്ത ഒരു ടണലിലേക്ക് ബന്ധിപ്പിച്ചിരിക്കും.

വിന്യാസം സാധാരണയായി ഒരു MDM അല്ലെങ്കിൽ മാനേജ്ഡ് കോൺഫിഗറേഷനിലൂടെയാണ്, ഉപയോക്താവ് ഫീൽഡുകൾ ടൈപ്പ് ചെയ്യുന്നതിലൂടെയല്ല. ആ ഇൻഫ്രാസ്ട്രക്ചർ ഇപ്പോഴും ഇല്ലെങ്കിൽ, മൈഗ്രേഷൻ പ്ലാനിൽ അത് ഉൾപ്പെടുത്തണം, കാരണം ഓരോ ഉപകരണത്തിലും IKEv2 പ്രൊഫൈൽ കൈകൊണ്ട് വീണ്ടും നൽകുന്നത് ഒരു ഹെൽപ്പ് ഡെസ്കിന് ഏറ്റെടുക്കാവുന്ന പ്രവർത്തനമല്ല.

പാത മൂന്ന്: തേർഡ്-പാർട്ടി ക്ലയന്റ് ആപ്പ്

ചില VPN ആപ്പുകൾ സ്വന്തം പ്രോട്ടോക്കോൾ ഇംപ്ലിമെന്റേഷൻ നൽകുന്നു, നേറ്റീവ് ലെഗസി സ്റ്റാക്കിനെ ആശ്രയിക്കുന്നില്ല. അത് വേഗത്തിൽ മൈഗ്രേറ്റ് ചെയ്യാൻ കഴിയാത്ത ഫ്ലീറ്റിന് അവയെ സാധുവായ ഒരു താൽക്കാലിക പരിഹാരമാക്കുന്നു, പക്ഷേ അനുയോജ്യതാ ചോദ്യം ആപ്പിലേക്ക് നീങ്ങുന്നു: നിങ്ങളുടെ ഗേറ്റ്വേ സംസാരിക്കുന്ന അതേ IKEv1 മോഡ്, ഗേറ്റ്വേ ആവശ്യപ്പെടുന്ന ഓതന്റിക്കേഷനും സൈഫർ സ്യൂട്ടുകളും ഉപയോഗിച്ച് അത് നടപ്പാക്കുന്നുണ്ടോ എന്ന്.

സ്റ്റോർ വിവരണത്തെക്കാൾ ആപ്പിന്റെ സ്വന്തം സപ്പോർട്ട് മാട്രിക്സിനെ അധികാരമായി കാണുക, ശുപാർശ ചെയ്യുന്നതിന് മുമ്പ് യഥാർത്ഥ ഗേറ്റ്വേയ്ക്കെതിരെ ഒരു യഥാർത്ഥ ഉപകരണം പരീക്ഷിക്കുക. നീക്കം ചെയ്ത ഒരു പ്ലാറ്റ്ഫോം പാത പുനഃസ്ഥാപിക്കാൻ ഫോൺ റൂട്ട് ചെയ്യുന്നതും പരിപാലിക്കപ്പെടുന്ന പരിഹാരമല്ല; അത് പ്രശ്നം അടുത്ത സിസ്റ്റം അപ്ഡേറ്റിന് നിശബ്ദമായി തകർക്കാവുന്ന പിന്തുണയില്ലാത്ത ഒരു കോൺഫിഗറേഷനിലേക്ക് മാറ്റുന്നു.

ഗേറ്റ്വേ എന്ത് നൽകാൻ കഴിയും എന്നതിനെ അടിസ്ഥാനമാക്കി തിരഞ്ഞെടുക്കുക

രണ്ട് കാര്യങ്ങൾ അറിയുമ്പോൾ തീരുമാനം ചുരുങ്ങുന്നു: ഏതൊക്കെ ഉപകരണങ്ങളാണ് API 31-ലോ അതിനുശേഷമോ ലോഞ്ച് ചെയ്തത്, കൂടാതെ അതേ എൻറോൾമെന്റ് മോഡലോടുകൂടി IKEv2 സേവനം അവതരിപ്പിക്കാൻ ഗേറ്റ്വേയ്ക്ക് കഴിയുമോ. കഴിയുമെങ്കിൽ, മൈഗ്രേറ്റ് ചെയ്ത് ലെഗസി പ്രൊഫൈലിൽ നിക്ഷേപം നിർത്തുക. ഇപ്പോഴും കഴിയില്ലെങ്കിൽ, അത് ഇപ്പോഴും ആരംഭിക്കുന്ന ഉപകരണങ്ങൾക്ക് IKEv1 നിലനിർത്തുക, പുതിയ ഉപകരണങ്ങൾക്ക് തേർഡ്-പാർട്ടി ക്ലയന്റ് ഒരു രേഖപ്പെടുത്തിയ, സമയപരിധിയുള്ള ഒഴിവാക്കലായി നൽകുക, പറയാത്ത ഒരു വഴിവെട്ടലായി അല്ല.

രണ്ട് പോയിന്റുകൾ പ്ലാനിനെ സംരക്ഷിക്കാവുന്നതാക്കുന്നു. ആദ്യം, ഓരോ ഒഴിവാക്കലിന്റെയും കാരണം മോഡലും ലോഞ്ച് ലെവലും സഹിതം രേഖപ്പെടുത്തുക, അതുവഴി പരിധി വിശദീകരിക്കാത്ത മുൻഗണനയല്ല, പ്ലാറ്റ്ഫോം ഗാർഡ് ആണെന്ന് ഒരു ഓഡിറ്റർക്ക് കാണാം. രണ്ടാമതായി, മൈഗ്രേഷനെ ആസൂത്രിത ജോലിയായി കാണുക: IKEv1 സ്റ്റാൻഡേർഡ് ട്രാക്ക് പ്രകാരം കാലഹരണപ്പെട്ടതാണ് (RFC 9395), അതായത് ബാക്കിയുള്ള ഉപകരണങ്ങൾ ചുരുങ്ങിക്കൊണ്ടിരിക്കും, ഒഴിവാക്കലുകൾ അവയോടൊപ്പം അവസാനിക്കണം.