iPhone IKEv2 മുതൽ RouterOS വരെ: ഏത് ഐഡന്റിഫയർ എവിടെ പോകുന്നു
iOS-ലെ IKEv2 തുരങ്കം നാല് വേറിട്ട അവകാശവാദങ്ങൾ തീരുമാനിക്കുന്നു: ഡയൽ ചെയ്യുന്ന വിലാസം, പ്രതീക്ഷിക്കുന്ന സെർവർ ഐഡന്റിറ്റി, അവകാശപ്പെടുന്ന ക്ലയന്റ് ഐഡന്റിറ്റി, സർട്ടിഫിക്കറ്റ് വസ്തു.
MikroTik ഗേറ്റ്വേയിൽ എത്തുന്നത് IKEv2 വിന്യാസത്തിന്റെ ഗതാഗത പകുതി മാത്രമേ പരിഹരിക്കുന്നുള്ളൂ, അതിൽ കൂടുതലൊന്നുമില്ല. തുടർന്ന് നാല് വേറിട്ട അവകാശവാദങ്ങൾ തുരങ്കം രൂപപ്പെടുമോ എന്ന് തീരുമാനിക്കുന്നു: ഫോൺ ഡയൽ ചെയ്യുന്ന വിലാസം, അത് പ്രതീക്ഷിക്കുന്ന സെർവർ ഐഡന്റിറ്റി, അത് സ്വയം അവകാശപ്പെടുന്ന ഐഡന്റിറ്റി, ആ അവകാശവാദത്തെ പിന്തുണയ്ക്കുന്ന സർട്ടിഫിക്കറ്റ് വസ്തു. അവ ആ ക്രമത്തിൽ പരിശോധിക്കുക, ഗേറ്റ്വേ അവതരിപ്പിക്കുന്നതുമായി പൊരുത്തപ്പെടാത്ത ആദ്യത്തേതിൽ നിർത്തുക. ഓരോന്നും വ്യത്യസ്ത സ്ഥലത്ത് എഡിറ്റ് ചെയ്യുന്നു, അതിനാൽ തെറ്റായ എഡിറ്റ് സാധാരണയായി പരാജയം പരിഹരിക്കുന്നതിനുപകരം സ്ഥാനം മാറ്റുന്നു.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
കൈമാറ്റം ഉപയോഗിക്കുന്ന ക്രമത്തിൽ പ്രൊഫൈൽ ഫീൽഡുകൾ പരിശോധിക്കുക
വിദൂര വിലാസം ആദ്യ IKE പാക്കറ്റിന്റെ ലക്ഷ്യസ്ഥാനം മാത്രമാണ്. വിദൂര ഐഡന്റിഫയർ ഫോൺ ഗേറ്റ്വേ താൻ തന്നെയാണെന്ന് തെളിയിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നതാണ്, അത് ഒരു പേരാണ്, റൂട്ടല്ല. രണ്ടും ഒരേ ഹോസ്റ്റ്നാമിൽ നിറയ്ക്കുന്നത് ഗേറ്റ്വേയുടെ സർട്ടിഫിക്കറ്റിൽ ആ പേരുണ്ടെങ്കിൽ പ്രവർത്തിക്കും, ഇല്ലെങ്കിൽ റൂട്ടിംഗ് പ്രശ്നമായി തോന്നിക്കുന്ന രീതിയിൽ പരാജയപ്പെടും. പ്രൊഫൈൽ പൂരിപ്പിക്കേണ്ട ഫീൽഡുകളുടെ പട്ടികയായല്ല, അവകാശവാദങ്ങളുടെ ക്രമമായി വായിക്കുക.
പ്രാദേശിക ഐഡന്റിഫയർ ഫോണിന്റെ സ്വന്തം അവകാശവാദമാണ്, ഫോൺ അവതരിപ്പിക്കുന്ന ക്ലയന്റ് സർട്ടിഫിക്കറ്റിന് RouterOS ഐഡന്റിറ്റി എൻട്രി സ്വീകരിക്കുന്ന പേരായിരിക്കണം. രണ്ടും പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, സർട്ടിഫിക്കറ്റ് തന്നെ സാധുതയുള്ളതായതിന് ശേഷം ഗേറ്റ്വേ കണക്ഷൻ നിരസിക്കും, ലോഗ് പേരിടലിന്റെയല്ല, അനുമതിയുടെ പ്രശ്നമായി തോന്നും.
ഗേറ്റ്വേ അവതരിപ്പിക്കുന്നതിനെതിരെ ഐഡന്റിഫയറുകൾ പരിശോധിക്കുക
സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണത്തിനായി ക്രമീകരിച്ച RouterOS പിയർ എൻട്രി സ്വന്തം സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു, മറ്റൊരു രീതിയിൽ ക്രമീകരിച്ചിട്ടില്ലെങ്കിൽ അതിന്റെ ഐഡന്റിറ്റി ആ സർട്ടിഫിക്കറ്റിൽ നിന്നാണ് എടുക്കുന്നത്. ഫോണിന്റെ വിദൂര ഐഡന്റിഫയർ ഗേറ്റ്വേയുടെ DNS പേര് പറയുന്നുവെങ്കിൽ, ഗേറ്റ്വേയുടെ സർട്ടിഫിക്കറ്റിന് ആ പേര് ഫോൺ സ്വീകരിക്കുന്ന ഇടത്ത്, സാധാരണയായി വിഷയത്തിന്റെ ഇതര നാമത്തിൽ ആവശ്യമാണ്. മറ്റൊരു പൊതു നാമത്തിന് നൽകിയ സർട്ടിഫിക്കറ്റ് കീയും ശൃംഖലയും തികഞ്ഞതാണെങ്കിലും സാധുതയുള്ളതാകില്ല.
നിയന്ത്രിത Apple പ്രൊഫൈലുകൾക്ക് ഐഡന്റിഫയർ ഫീൽഡുകൾക്ക് പുറമേ വിലയിരുത്തുന്ന സർട്ടിഫിക്കറ്റ്-നാമ നിയന്ത്രണവുമുണ്ടാകാം. സെറ്റിംഗ്സ് സ്ക്രീൻ കാണിക്കുന്നതിൽ നിന്ന് സാധുതാ നാമം അനുമാനിക്കുന്നതിനുപകരം പേലോഡ് പരിശോധിക്കുക, കാരണം രണ്ടും ഒരേ സെറ്റിംഗ് അല്ല.
ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ഒരു കീയാണെന്ന് പരിശോധിക്കുക, വെറും വിശ്വാസ ആങ്കർ മാത്രമല്ല
CA സർട്ടിഫിക്കറ്റ് ഇറക്കുമതി ചെയ്യുന്നത് ഗേറ്റ്വേ സാധൂകരിക്കാൻ ഫോണിന് എന്തെങ്കിലും നൽകുന്നു. അത് ഫോണിന് ക്ലയന്റ് ഐഡന്റിറ്റി നൽകുന്നില്ല, സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണത്തിന് ക്ലയന്റ് ഇല സർട്ടിഫിക്കറ്റും അതിന്റെ സ്വകാര്യ കീയും അംഗീകൃത രജിസ്ട്രേഷൻ പാതയിലൂടെ ഒരുമിച്ച് എത്തിക്കേണ്ടതുണ്ട്. സ്വകാര്യ കീയില്ലാതെ നിർമ്മിച്ച PKCS#12 വൃത്തിയായി ഇൻസ്റ്റാൾ ചെയ്യുന്നതും ഒന്നും പ്രാമാണീകരിക്കാത്തതുമായ പ്രൊഫൈൽ നൽകുന്നു.
ക്ലയന്റ് ഇലയ്ക്ക് RouterOS വശം പ്രതീക്ഷിക്കുന്ന ഐഡന്റിറ്റിയും ആവശ്യമാണ്, അതായത് വിഷയമോ വിഷയത്തിന്റെ ഇതര നാമമോ ബന്ധപ്പെട്ട ഐഡന്റിറ്റി കോൺഫിഗറേഷനുമായി പൊരുത്തപ്പെടണം. ഒരേ CA-യിൽ നിന്ന് ക്ലയന്റ്, സെർവർ സർട്ടിഫിക്കറ്റുകൾ നൽകുന്നത് ശൃംഖല സൗകര്യപ്രദമാക്കുന്നു, രണ്ട് ഇലകളെ പരസ്പരം മാറ്റാവുന്നതാക്കുന്നില്ല.
RouterOS നയം ആ പേര് സ്വീകരിക്കുന്നുവെന്ന് പരിശോധിക്കുക
ഗേറ്റ്വേയിൽ പിയർ എൻട്രി കൈമാറ്റ മോഡും പ്രാമാണീകരണ രീതിയും നിശ്ചയിക്കുന്നു, ഐഡന്റിറ്റി എൻട്രി സ്വീകരിച്ച വിദൂര ഐഡന്റിറ്റിയെ സർട്ടിഫിക്കറ്റുമായും തുടർന്നുള്ള നയവുമായും ബന്ധിപ്പിക്കുന്നു. RouterOS v7-ൽ ഈ ജോഡി IPsec പിയർ, ഐഡന്റിറ്റി എൻട്രികളിലൂടെ പ്രകടിപ്പിക്കുന്നു, ഉദാഹരണത്തിന് auth-method=digital-signature ഉള്ള IKEv2 പിയർ. പഴയ പതിപ്പിനായി എഴുതിയ മാർഗ്ഗനിർദ്ദേശമല്ല, നിങ്ങളുടെ ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പിലെ യഥാർത്ഥ മെനു ഉള്ളടക്കം പരിശോധിക്കുക.
ഇവിടെയാണ് പൊരുത്തക്കേട് പരിഹരിക്കാൻ ഏറ്റവും വിലകുറവ്, കാരണം ഗേറ്റ്വേയ്ക്ക് ലഭിച്ചതും ആഗ്രഹിച്ചതുമായ ഐഡന്റിറ്റി നിങ്ങളോട് പറയാൻ കഴിയും. പിശക് ശാന്തമാക്കാൻ സ്വീകരിക്കുന്ന ഐഡന്റിറ്റി വിശാലമാക്കുന്നത് വിന്യാസത്തിന് അർത്ഥം നൽകിയ ബന്ധം നീക്കം ചെയ്യുന്നു.
എന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഏത് ഘട്ടം പരാജയപ്പെട്ടുവെന്ന് പരിശോധിക്കുക
രണ്ടറ്റത്തും ശ്രമം വായിച്ച് നിർദ്ദേശം മാറ്റുന്നതിന് മുമ്പ് തരംതിരിക്കുക. നിർദ്ദേശ പൊരുത്തക്കേട്, നഷ്ടമായ ഒപ്പ് കീ, വിശ്വസനീയമല്ലാത്ത പുറപ്പെടുവിക്കുന്നയാൾ, തെറ്റായ പിയർ ഐഡന്റിഫയർ, നിരസിച്ച ക്ലയന്റ് അനുമതി — എല്ലാം ഫോണിൽ നിന്ന് മരിച്ച തുരങ്കമായി തോന്നും, ഓരോന്നിനും വേറെ ഉടമയുണ്ട്. അഞ്ച് ക്രമീകരണങ്ങളും ഒരുമിച്ച് മാറ്റുന്നത് ഫലത്തിൽ നിന്ന് നിങ്ങൾ ഒന്നും പഠിക്കില്ലെന്ന് ഉറപ്പാക്കുന്നു.
അവതരിപ്പിച്ച ഐഡന്റിറ്റി, പ്രതീക്ഷിച്ച ഐഡന്റിറ്റി, സർട്ടിഫിക്കറ്റിന്റെ പുറപ്പെടുവിക്കുന്നയാളും ക്രമ നമ്പറും, ബന്ധപ്പെട്ട നയത്തിന്റെ പേരും രേഖപ്പെടുത്തുക, സ്വകാര്യ കീകളും പ്രൊഫൈൽ രഹസ്യങ്ങളും ആ രേഖയ്ക്ക് പുറത്ത് സൂക്ഷിക്കുക. പ്രാമാണീകരണം വിജയിച്ചാൽ, ഒരു സ്വകാര്യ സേവനവും അതിന്റെ പ്രതികരണവും പരിശോധിക്കുക, കാരണം IKE കൈമാറ്റം കഴിഞ്ഞതിന് ശേഷവും വിലാസ വിഭജനം, സെലക്ടറുകൾ, DNS, പ്രവേശന നയം എന്നിവ പ്രവർത്തിക്കണം.