Android VPN മുതൽ Cisco IOS വരെ: ആദ്യം വാങ്ങേണ്ട കരാർ

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

ആദ്യം വേണ്ടത് ഒരു കണക്ഷൻ കരാറാണ്: പ്രോട്ടോക്കോൾ, പ്രാമാണീകരണം, ഐഡന്റിറ്റി, വിശ്വാസ വസ്തു, വിലാസ വിന്യാസം, റൂട്ടിംഗ്, ഗേറ്റ്‌വേ നടത്തുന്നയാൾ എഴുതി നൽകണം.

അത് എഴുത്തിൽ കിട്ടിയാൽ ക്ലയന്റ് തിരഞ്ഞെടുപ്പ് ഒരു തിരയലാകും. ഒഴിവാക്കിയാൽ ഓരോ പരാജയവും തെറ്റായ പാസ്‌വേഡ് പോലെ തോന്നും.

എന്തും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് മുൻപ് വിവരശേഖരണം നടത്തുക

ഗേറ്റ്‌വേ ഉടമയ്ക്ക് ഒരു പട്ടിക അയച്ച് ഉൽപ്പന്നത്തിന്റെ പേരല്ല, ഉത്തരങ്ങൾ ആവശ്യപ്പെടുക. ഒമ്പത് ഇനങ്ങൾ റിമോട്ട്-ആക്സസ് പ്രൊഫൈലിനെ പൂർണ്ണമായി ഉൾക്കൊള്ളുന്നു:

1. ക്ലയന്റ് ഡയൽ ചെയ്യേണ്ട ഗേറ്റ്‌വേയുടെ ഹോസ്റ്റ്നാമോ വിലാസമോ, അത് പുറത്തുനിന്ന് എത്താനാകുമോ.
2. പ്രോട്ടോക്കോളും പതിപ്പും: IKEv2, IPsec-ന്റെ മറ്റൊരു തലമുറ, അല്ലെങ്കിൽ TLS അധിഷ്ഠിത സേവനം.
3. ഗേറ്റ്‌വേ പ്രതീക്ഷിക്കുന്ന പിയർ ഐഡന്റിറ്റിയും അത് പ്രതിഫലമായി അവതരിപ്പിക്കുന്നതും.
4. വിശ്വാസ വസ്തു: ഏത് CA യാണ് ഗേറ്റ്‌വേ സർട്ടിഫിക്കറ്റ് ഒപ്പിടുന്നത്, അല്ലെങ്കിൽ മുൻകൂട്ടി പങ്കിട്ട കീ ഉപയോഗിക്കുന്നുണ്ടോ.
5. ഉപയോക്തൃ പ്രാമാണീകരണം: സർട്ടിഫിക്കറ്റ്, EAP ഉപയോക്തൃനാമവും പാസ്‌വേഡും, അല്ലെങ്കിൽ മുൻകൂട്ടി പങ്കിട്ട കീ.
6. ക്ലയന്റ് എത്തുന്ന വിലാസ കൂട്ടം, മാസ്കും ഗേറ്റ്‌വേയും സഹിതം.
7. ടണലിനുള്ളിൽ ഉപയോഗിക്കേണ്ട DNS സെർവറുകൾ, ക്ലയന്റ് അവ സ്വീകരിക്കണമോ.
8. അനുവദനീയ ലക്ഷ്യ പ്രിഫിക്സുകൾ, അവയ്ക്ക് പുറത്തുള്ള ട്രാഫിക് തടയണമോ.
9. പിന്തുണയ്ക്കുന്ന ക്ലയന്റ് പതിപ്പുകളും ഫോണിന്റെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം പതിപ്പുകളും, കൂടാതെ രജിസ്ട്രേഷൻ ആവശ്യകതയുണ്ടെങ്കിൽ അതും.

ഈ ഇനങ്ങളിൽ രണ്ടെണ്ണം ഒഴിവാക്കാവുന്ന പരാജയങ്ങളിൽ ഭൂരിഭാഗത്തിനും കാരണമാകുന്നു. വിശ്വാസ വസ്തു ഇല്ലാതെ ഗേറ്റ്‌വേ സാധൂകരിക്കാനാവില്ല, അതിനാൽ ശരിയായ ക്ലയന്റും കേടായതുപോലെ തോന്നും. അനുവദനീയ പ്രിഫിക്സുകൾ ഇല്ലാതെ റൂട്ടിംഗ് നിയന്ത്രണത്തെ സേവന പ്രശ്നത്തിൽനിന്ന് വേർതിരിക്കാനാവില്ല.

വിൽപ്പനക്കാരന്റെ പേര് പ്രോട്ടോക്കോളല്ല

Cisco IOS-ഉം IOS XE-യും പല റിമോട്ട്-ആക്സസ് ക്രമീകരണങ്ങൾ നൽകുന്നു, അവ ഒരേ വയർ ഫോർമാറ്റ് പങ്കിടുന്നില്ല. FlexVPN ശൈലിയിലുള്ള പ്രൊഫൈലുമായുള്ള IKEv2 പഴയ IKEv1 കോൺഫിഗറേഷനെപ്പോലെയുള്ള സേവനമല്ല, TLS അധിഷ്ഠിത ക്ലയന്റ് സേവനം വീണ്ടും മറ്റൊരു ഉൽപ്പന്നമാണ്, പലപ്പോഴും അതേ പരിതസ്ഥിതിയിൽ മറ്റൊരു പ്ലാറ്റ്ഫോമിൽ.

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

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

Android-ന്റെ ഉൾനിർമ്മിത സ്റ്റാക്ക് എന്തുൾക്കൊള്ളുന്നു

Android പ്ലാറ്റ്ഫോമിന്റെ IKEv2/IPsec പ്രൊഫൈൽ Ikev2VpnProfile വഴി നൽകുന്നു, മുൻകൂട്ടി പങ്കിട്ട കീ, RSA സർട്ടിഫിക്കറ്റ്, EAP ഉപയോക്തൃനാമവും പാസ്‌വേഡും എന്നിവയ്ക്ക് വെവ്വേറെ പ്രാമാണീകരണ തരങ്ങളോടെ. Ikev2VpnProfile റഫറൻസ് ബിൽഡർ എന്തു സ്വീകരിക്കുന്നു എന്നതിന്റെ അധികാര സ്രോതസ്സാണ്, അതിൽ ഗേറ്റ്‌വേയുടെ ഹോസ്റ്റ്നാമവും അത് സാധൂകരിക്കാൻ ഉപയോഗിക്കുന്ന സെർവർ റൂട്ട് CA-യും ഉൾപ്പെടുന്നു.

ആ API ഒരു കഴിവ് പ്രസ്താവനയാണ്, അനുയോജ്യതാ വാഗ്ദാനമല്ല. ആ പ്രാമാണീകരണ തരങ്ങളോടെ പ്ലാറ്റ്ഫോമിന് IKEv2 ചെയ്യാമെന്ന് അത് പറയുന്നു. ഒരു പ്രത്യേക OEM ക്രമീകരണ സ്ക്രീൻ എല്ലാ ഫീൽഡും കാണിക്കുന്നു എന്നോ, മറ്റൊരു ഉൽപ്പന്നത്തിൽനിന്ന് കയറ്റുമതി ചെയ്ത പ്രൊഫൈൽ ഫയൽ ഇറക്കുമതി ചെയ്യും എന്നോ അത് പറയുന്നില്ല.

ഗേറ്റ്‌വേ പ്ലാറ്റ്ഫോം നടപ്പാക്കാത്ത ഒരു സേവനം പ്രവർത്തിപ്പിക്കുന്നുണ്ടെങ്കിൽ ഉൾനിർമ്മിത സ്റ്റാക്ക് നിങ്ങളെ രക്ഷിക്കില്ല എന്നും ഇതിനർത്ഥമുണ്ട്. അങ്ങനെയെങ്കിൽ ഓപ്പറേറ്റർ പിന്തുണയ്ക്കുന്ന വിൽപ്പനക്കാരന്റെ ക്ലയന്റ് വേണം, ഓപ്പറേറ്റർ രേഖപ്പെടുത്തിയതുപോലെ ഇൻസ്റ്റാൾ ചെയ്ത് ക്രമീകരിച്ചത്, ഫോൺ സംസാരിക്കാത്ത പ്രോട്ടോക്കോളിൽ കെട്ടിയുണ്ടാക്കിയ ഒരു വഴിത്തിരിവല്ല.

കരാർ എഴുതിയ ക്രമത്തിൽ പരിശോധിക്കുക

ഒരു സമയം ഒരു പാളി സാധൂകരിച്ച് ആദ്യ പരാജയത്തിൽ നിർത്തുക, കാരണം മുൻപുള്ളവ കടക്കാതെ പിന്നീടുള്ള പരിശോധനകൾക്ക് അർത്ഥമില്ല.

വിശ്വാസം. ക്ലയന്റ് ഗേറ്റ്‌വേ സർട്ടിഫിക്കറ്റ് നിരസിച്ചാൽ മറ്റൊന്നും പ്രധാനമല്ല. നിങ്ങൾക്ക് നൽകിയ CA ഗേറ്റ്‌വേ അവതരിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റ് ഒപ്പിടുന്നുണ്ടെന്നും നിങ്ങൾ ഡയൽ ചെയ്ത ഹോസ്റ്റ്നാം അതിൽ ഉണ്ടെന്നും ഉറപ്പാക്കുക. സാധൂകരണം ഓണായി വയ്ക്കുക; അത് ഓഫാക്കുന്നത് ഐഡന്റിറ്റി പ്രശ്നത്തെ തടയലപ്പെടാനുള്ള അപകടമാക്കി മാറ്റുന്നു.

പ്രാമാണീകരണം. നിരസിക്കപ്പെട്ട ക്രെഡൻഷ്യലും പൊരുത്തപ്പെടാത്ത നിർദ്ദേശവും വ്യത്യസ്ത പിശകുകൾ എന്നാൽ ഒരുപോലെ തോന്നുന്ന പരാജയങ്ങൾ നൽകുന്നു. ഗേറ്റ്‌വേ ലോഗ് നിർണ്ണായകമാണ്: ഉപയോക്താവിനെക്കുറിച്ച് എന്തും പറയുന്നതിന് മുൻപ് നിർദ്ദേശം സ്വീകാര്യമായിരുന്നോ എന്ന് അത് പറയും.

വിലാസവും DNS-ഉം. ഫോണിന് രേഖപ്പെടുത്തിയ കൂട്ടത്തിൽനിന്ന് വിലാസം ലഭിച്ചുവെന്ന് ഉറപ്പാക്കുക, എന്നിട്ട് ഒരു ആന്തരിക നാമം പരിഹരിക്കുക. വിലാസത്തോടെയും എന്നാൽ റിസോൾവറില്ലാതെയും ഉയരുന്ന ടണൽ ബന്ധിപ്പിച്ചതുപോലെ തോന്നുകയും ഒന്നും പ്രവർത്തിക്കാത്തതുപോലെ പെരുമാറുകയും ചെയ്യും.

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

പരാജയ മാതൃകകളും റോൾബാക്കും

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് മുൻപത്തെ പ്രവർത്തനക്ഷമമായ പ്രൊഫൈൽ കയറ്റുമതി ചെയ്ത് രേഖപ്പെടുത്തിയതായി സൂക്ഷിക്കുക, CA ഉപനാമവും വിലാസ കൂട്ടവും ഉൾപ്പെടെ. അപ്പോൾ റോൾബാക്ക് എന്നാൽ അറിയപ്പെടുന്ന ഒരു പ്രൊഫൈൽ പുനഃസ്ഥാപിക്കുക എന്നതാണ്, തടസ്സവേളയിൽ ഓർമ്മയിൽനിന്ന് അത് വീണ്ടും കെട്ടിയുണ്ടാക്കുകയല്ല.

അത് പ്രവർത്തിക്കുമ്പോൾ, ഒമ്പത് ശേഖരണ ഉത്തരങ്ങളും പ്രൊഫൈലിന് അടുത്തായി രേഖപ്പെടുത്തുക. അടുത്ത ഫോൺ, അടുത്ത OS അപ്ഡേറ്റ്, അടുത്ത ഗേറ്റ്‌വേ മാറ്റം—എല്ലാം ഒരു രേഖയുമായുള്ള താരതമ്യമാകും, മറ്റൊരു ഉച്ചതിരിഞ്ഞത്തിലെ ഊഹത്തിനുപകരം.