iPhone-ൽ IKEv2 സർട്ടിഫിക്കറ്റ് സെറ്റപ്പ്: മാനുവൽ അല്ലെങ്കിൽ മാനേജ്ഡ് രജിസ്ട്രേഷൻ

ഗേറ്റ്‌വേയുടെ സർട്ടിഫിക്കറ്റ് ടൂൾ ഡിഫോൾട്ടായി RSA ഉപയോഗിക്കുന്നു എന്ന കാരണത്താൽ അത് തിരഞ്ഞെടുക്കുന്നത് പ്രധാനമായ ചോദ്യത്തിന് മുമ്പ് എടുക്കുന്ന തീരുമാനമാണ്: ഈ iPhone-കൾ എങ്ങനെ രജിസ്റ്റർ ചെയ്യും? ഉപയോക്താവ് തന്നെ ടൈപ്പ് ചെയ്യുന്ന കണക്ഷനും മാനേജ്മെന്റ് നൽകുന്ന കോൺഫിഗറേഷൻ പ്രൊഫൈലും വ്യത്യസ്ത ക്രമീകരണങ്ങൾ കാണിക്കുന്നു, ചില സർട്ടിഫിക്കറ്റ് ഓപ്ഷനുകൾ ഈ രണ്ട് പാതകളിൽ ഒന്നിൽ മാത്രമേ നിലനിൽക്കുന്നു. ക്രമം ശരിയാക്കിയാൽ സർട്ടിഫിക്കറ്റ് പ്ലാൻ ചെറുതാകും; തെറ്റിയാൽ ഫോൺ ഉപയോഗിക്കാത്ത ഒരു ക്രെഡൻഷ്യൽ നിങ്ങൾ നൽകും. താഴെയുള്ള ഘട്ടങ്ങളെ ഒരു ക്രമമായി കാണുക, കാരണം ഓരോന്നും അടുത്തതിന് ലഭ്യമായ ഓപ്ഷനുകൾ ചുരുക്കുന്നു.

ആദ്യ ഘട്ടം: രജിസ്ട്രേഷൻ പാത തിരഞ്ഞെടുക്കുക

മാനുവൽ സെറ്റപ്പ് എന്നാൽ ഉപയോക്താവ് സെർവർ വിലാസം നൽകി, പ്രാമാണീകരണ രീതി തിരഞ്ഞെടുത്ത്, ഇന്റർഫേസ് അനുവദിക്കുന്ന ഏത് ക്രെഡൻഷ്യലും നൽകുന്നു. മാനേജ്ഡ് രജിസ്ട്രേഷൻ എന്നാൽ പ്രൊഫൈൽ വിലാസവും ഐഡന്റിഫയറുകളും ക്രെഡൻഷ്യൽ പേലോഡിലേക്കുള്ള റഫറൻസും വഹിക്കുന്നു. മാനുവൽ സ്ക്രീനിന് പ്രകടിപ്പിക്കാൻ കഴിയാത്ത സംയോജനങ്ങൾ മാനേജ്ഡ് പാതയ്ക്ക് പ്രകടിപ്പിക്കാം, അതിനാൽ സർട്ടിഫിക്കറ്റ് തീരുമാനം ഈ തിരഞ്ഞെടുപ്പിന് ശേഷം വരണം, മുമ്പല്ല.

രണ്ട് പാതകൾക്കും ഒരു ഫോണിനെ പ്രാമാണീകരിക്കാം. എന്ത് കോൺഫിഗർ ചെയ്യാം, ഐഡന്റിറ്റി ആർക്ക് സ്വന്തം എന്നതിൽ അവ വ്യത്യസ്തമാണ്, അതിനാൽ മാനേജ്ഡ് പ്രൊഫൈൽ മാനുവൽ ക്രെഡൻഷ്യൽ എൻട്രിയുമായി കലർത്തുന്നതിനുപകരം ഒന്ന് ബോധപൂർവം തിരഞ്ഞെടുക്കുക.

രണ്ടാം ഘട്ടം: തിരഞ്ഞെടുത്ത പാതയ്ക്കുള്ള അൽഗോരിതങ്ങൾ തിരഞ്ഞെടുക്കുക

മാനുവലായി കോൺഫിഗർ ചെയ്ത iPhone-കൾക്ക്, strongSwan-ന്റെ iOS പരസ്പരപ്രവർത്തന കുറിപ്പുകൾ RSA സെർവർ സർട്ടിഫിക്കറ്റ് ശുപാർശ ചെയ്യുന്നു, കാരണം മാനുവൽ ക്ലയന്റ് ECDSA സെർവർ സർട്ടിഫിക്കറ്റ് സ്വീകരിച്ചേക്കില്ല; അതേ കുറിപ്പുകൾ macOS-നെ വെവ്വേറെ കൈകാര്യം ചെയ്യുന്നു. ഇത് പിന്തുണയുള്ള ക്ലയന്റ് സെറ്റിനുള്ള മാർഗ്ഗനിർദ്ദേശമായി വായിക്കുക, Apple ഉപകരണങ്ങളെക്കുറിച്ചുള്ള ശാശ്വത നിയമമായി അല്ല. മാനേജ്ഡ് പ്രൊഫൈലിന് കൂടുതൽ ഇടമുണ്ട്: പേലോഡും ഗേറ്റ്‌വേയും രണ്ടും പിന്തുണയ്ക്കുമ്പോൾ അത് ECDSA ക്ലയന്റ് ഐഡന്റിറ്റി ഉൾപ്പെടെ സർട്ടിഫിക്കറ്റ് തരം വ്യക്തമായി തിരഞ്ഞെടുക്കാം.

എന്തെങ്കിലും വിന്യസിക്കുന്നതിന് മുമ്പ് നിങ്ങൾ യഥാർത്ഥത്തിൽ പിന്തുണയ്ക്കുന്ന iOS പതിപ്പുകൾ സാധൂകരിക്കുക. ഏറ്റവും പുതിയ പതിപ്പിലുള്ള ലാബ് ഫോൺ പഴയ ഉപകരണങ്ങൾ ഉൾപ്പെടുന്ന ഒരു ഫ്ലീറ്റിനെ വിവരിക്കുന്നില്ല, ലാബിൽ പ്രവർത്തിക്കുന്ന അൽഗോരിതം ഫീൽഡിലെ ഏറ്റവും പഴയ ഫോണിൽ പരാജയപ്പെടാനും ഇടയുണ്ട്. പതിപ്പ് ശ്രേണി ഓർമ്മയിൽ നിന്നല്ല, ഉപകരണ മാനേജ്മെന്റിൽ നിന്ന് എടുക്കുക. ഫ്ലീറ്റ് നിരവധി പതിപ്പുകളിലായി വ്യാപിക്കുന്നുവെങ്കിൽ, ആദ്യം ഏറ്റവും പഴയത് പരിശോധിക്കുക, കാരണം മാനുവൽ ഇന്റർഫേസ് ഏറ്റവും നിയന്ത്രിതമായത് അവിടെയാണ്.

മൂന്നാം ഘട്ടം: പ്രൊഫൈൽ ഫീൽഡുകൾ വെവ്വേറെ കാര്യങ്ങളായി വായിക്കുക

സമാനമായ പേരുള്ള നിരവധി കീകൾ വ്യത്യസ്ത ഒബ്ജക്റ്റുകളെ വിവരിക്കുന്നു. റിമോട്ട് വിലാസം ഫോൺ വിളിക്കുന്ന ഹോസ്റ്റാണ്. റിമോട്ട് ഐഡന്റിഫയർ ഗേറ്റ്‌വേ അവതരിപ്പിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്ന IKE ഐഡന്റിറ്റിയാണ്. പേലോഡിലെ സർട്ടിഫിക്കറ്റ് റഫറൻസ് ക്ലയന്റ് ക്രെഡൻഷ്യലിലേക്ക് ചൂണ്ടുന്നു, സർട്ടിഫിക്കറ്റ് തരം ഫീൽഡ് IKEv2 മെഷീൻ പ്രാമാണീകരണത്തിന് ഉപയോഗിക്കുന്ന തരം തിരഞ്ഞെടുക്കുന്നു. വാക്കുകൾ ഒത്തുപോകുന്നുവെങ്കിലും ഇവയൊന്നും CA-യുടെ ഒപ്പ് അൽഗോരിതമല്ല.

Apple-ന്റെ IKEv2 പേലോഡ് റഫറൻസ് വ്യക്തമായ ECDSA വകഭേദങ്ങളോടെ RSA-യെ ഡിഫോൾട്ട് സർട്ടിഫിക്കറ്റ് തരമായി പട്ടികപ്പെടുത്തുന്നു, ഇഷ്യൂവർ-നാമ കീയെ പ്രത്യേക പ്രാമാണീകരണ ക്രമീകരണങ്ങളുമായി ബന്ധിപ്പിക്കുന്നു. പ്രവർത്തിക്കുന്ന വിന്യാസത്തിൽ നിന്ന് ഒരു കീ പകർത്തുന്നതിനുപകരം തിരഞ്ഞെടുത്ത രീതിയുടെ റഫറൻസിൽ ആ ബന്ധങ്ങൾ വായിക്കുക.

നാലാം ഘട്ടം: ഗേറ്റ്‌വേ ഐഡന്റിറ്റി അതിന്റെ സർട്ടിഫിക്കറ്റുമായി യോജിപ്പിക്കുക

വ്യക്തമായ ഒരു ഗേറ്റ്‌വേ നാമം ഉപയോഗിക്കുക, ഉദാഹരണത്തിന് vpn.example.com എന്നിട്ട് സെർവർ സർട്ടിഫിക്കറ്റിൽ യോജിക്കുന്ന ഒരു ഇതര വിഷയ നാമം ചേർക്കുക. strongSwan-ന്റെ Apple മാർഗ്ഗനിർദ്ദേശം സെർവർ പ്രാമാണീകരണത്തിനുള്ള വിപുലീകൃത കീ ഉപയോഗവും പ്രതീക്ഷിക്കുന്നു. RSA അല്ലെങ്കിൽ ECDSA തിരഞ്ഞെടുക്കുന്നത് അതിൽ ഒന്നും മാറ്റുന്നില്ല: ഒരു അൽഗോരിതത്തിന് പേരിലെ പൊരുത്തക്കേടോ കാണാത്ത EKU-യോ അപൂർണ്ണമായ ചെയിനോ നന്നാക്കാൻ കഴിയില്ല.

ട്രസ്റ്റ് ആങ്കർ വിതരണം ഐഡന്റിറ്റി അവകാശപ്പെടുന്നതിൽ നിന്ന് വേറിട്ട ജോലിയാണ്. ഫോണിന് സാധൂകരിക്കാൻ കഴിയുന്ന ഒരു സർട്ടിഫിക്കറ്റ് ചെയിൻ വേണം, സർട്ടിഫിക്കറ്റിൽ നിങ്ങൾ യഥാർത്ഥത്തിൽ ചേർത്ത പേര് പ്രതീക്ഷിക്കാൻ അത് ക്രമീകരിക്കണം.

മറ്റൊരു പ്ലാറ്റ്ഫോം വിജയകരമായി കണക്ട് ചെയ്യുന്നത് ആ പ്ലാറ്റ്ഫോമിന്റെ വാലിഡേഷൻ നിയമങ്ങളുടെ തെളിവാണ്, ഫോണിന്റെ നിയമങ്ങൾ അയയ്ക്കാനുള്ള അനുമതിയല്ല. വ്യത്യാസപ്പെടാൻ രേഖപ്പെടുത്തിയ കാരണമില്ലെങ്കിൽ ക്ലയന്റുകൾക്കിടയിൽ പരിശോധനകൾ ഒരേപോലെ നിലനിർത്തുക.

അഞ്ചാം ഘട്ടം: ക്ലയന്റ് ഐഡന്റിറ്റിയെ CA വിശ്വാസത്തിൽ നിന്ന് വേർതിരിക്കുക

ക്ലയന്റ് സർട്ടിഫിക്കറ്റും അതിന്റെ സ്വകാര്യ കീയും ഫോൺ വിശ്വസിക്കുന്ന CA സർട്ടിഫിക്കറ്റിന്റെ അതേ ഒബ്ജക്റ്റല്ല. CA സർട്ടിഫിക്കറ്റ് PKCS#12 ഐഡന്റിറ്റിക്കുള്ളിൽ ബണ്ടിൽ ചെയ്യുന്നത് പിന്തുണയുള്ള എല്ലാ ഉപകരണത്തിലും അതിനെ സ്വയമേവ ട്രസ്റ്റ് ആങ്കറായി ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല, അതിനാൽ വിശ്വാസ വിതരണത്തെ സ്വന്തം പരിശോധനയുള്ള വേറിട്ട ഘട്ടമായി കാണുക.

ഡിസൈൻ പകരം പാസ്‌വേഡ് അടിസ്ഥാനമാക്കിയ EAP ഉപയോഗിക്കുന്നുവെങ്കിൽ, ഫോണിന് ഉദ്ദേശിച്ച അക്കൗണ്ട് പ്രാമാണീകരണവും സെർവർ സാധൂകരണവും വേണം. ആ പാത മുഴുവൻ ഫ്ലീറ്റിനും ഒരു പങ്കിട്ട ക്ലയന്റ് സ്വകാര്യ കീ അയയ്ക്കുന്നത് ന്യായീകരിക്കുന്നില്ല, അത് വളരെ മോശം പരാജയ രീതിയുള്ള മറ്റൊരു ഡിസൈനാണ്.

പുതുക്കലും റദ്ദാക്കലും മനസ്സിൽ വെച്ച് പ്ലാൻ പൂർത്തിയാക്കുക: ക്ലയന്റ് ക്രെഡൻഷ്യൽ ആര് വീണ്ടും നൽകുന്നു, പ്രൊഫൈൽ എങ്ങനെ അപ്ഡേറ്റ് ചെയ്യുന്നു, നഷ്ടപ്പെട്ട ഫോൺ എങ്ങനെ വിച്ഛേദിക്കുന്നു. നിങ്ങൾ സാധൂകരിച്ച പ്രൊഫൈൽ പതിപ്പും ഉപകരണ പതിപ്പുകളും രേഖപ്പെടുത്തുക, കാരണം ആ രേഖയാണ് അടുത്ത സർട്ടിഫിക്കറ്റ് മാറ്റത്തെ സാധാരണ ജോലിയാക്കുന്നത്.