MSCHAPv2 ഒരു VPN പ്രോട്ടോക്കോൾ അല്ല: ആദ്യം ടണലിനെക്കുറിച്ച് ചോദിക്കുക

ഉപയോക്തൃനാമങ്ങളും പാസ്വേഡുകളും ഒരു വാഹകനുള്ളിൽ യാത്ര ചെയ്യുന്നു, MSCHAPv2 യാത്ര ചെയ്യുന്ന രീതിയുടെ പേര് മാത്രം പറയുന്നു. ക്ലയന്റ് പ്രൊഫൈൽ തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ഏത് ടണൽ അത് വഹിക്കുന്നു എന്ന് ചോദിക്കുക, കാരണം അതേ അക്കൗണ്ട് സ്ട്രിംഗ് ഒരു വരി കോഡും പങ്കിടാത്ത ക്രമീകരണങ്ങളിലും കാണുന്നു. നിങ്ങൾക്ക് നൽകുന്ന ഓരോ പ്രൊഫൈലും രണ്ട് തീരുമാനങ്ങളും എൻകോഡ് ചെയ്യുന്നു, നിർദ്ദേശപത്രിക അവയിൽ ഒന്ന് മാത്രം അച്ചടിച്ചാലും. താഴെയുള്ള ക്രമമാണ് ഓപ്പറേറ്റർ ഊഹിക്കാതെ ഉത്തരം നൽകാൻ കഴിയുന്നതും പാക്കറ്റ് പിടിക്കാതെ നിങ്ങൾക്ക് പരിശോധിക്കാൻ കഴിയുന്നതും.

പ്രാമാണീകരണം ടണലിനുള്ളിൽ സഞ്ചരിക്കുന്നു

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

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

അതേ രീതി പ്രത്യക്ഷപ്പെടുന്ന മൂന്ന് സ്ഥലങ്ങൾ

PPP യിൽ പ്രാമാണീകരണ ഘട്ടം ഒരു ലിങ്ക് ഉണ്ടാകുന്നതുവരെ കാത്തിരിക്കുന്നു, RFC 2759 MS-CHAPv2 അതേ ഘട്ടമായി നിർവചിക്കുന്നു, അതുകൊണ്ടാണ് ഈ രീതി L2TP പഴയ PPTP വിന്യാസങ്ങളിലും കാണുന്നത്. ടണൽ ആദ്യം അവസാനിക്കുന്നു, PPP ചർച്ച അതിനുള്ളിൽ നടക്കുന്നു, അതിനാൽ പരാജയപ്പെട്ട PPP ഘട്ടം സർവർ ലോഗിൽ ടണൽ സ്ഥാപിതമായതുപോലെ നിലനിർത്തിയേക്കാം. ക്രെഡൻഷ്യലുകൾ നിരസിക്കപ്പെട്ടു എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് ആ രണ്ട് ഘട്ടങ്ങളും വെവ്വേറെ വായിക്കുക. അതിനാൽ L2TP നായി ക്രമീകരിച്ച ക്ലയന്റ് പൂർണ്ണമായും ശരിയായിരിക്കാം, എന്നിട്ടും IKEv2 മാത്രം സംസാരിക്കുന്ന ഗേറ്റ്വേയ്ക്ക് തെറ്റായ ക്ലയന്റ് ആകാം.

IKEv2 പകരം EAP-MSCHAPv2 കീ കൈമാറ്റത്തിനുള്ളിൽ ഇടുന്നു, അതിനാൽ അതേ ക്രെഡൻഷ്യൽ മറ്റൊരു നിമിഷത്തിൽ പരാജയപ്പെട്ട് സെഷൻ പിശകല്ല, പ്രാമാണീകരണ പിശകായി പ്രത്യക്ഷപ്പെടുന്നു. Android പ്ലാറ്റ്ഫോമിന്റെ IKEv2 പ്രൊഫൈൽ ദൈനംദിന ഉദാഹരണമാണ്, അത് PPP ഓപ്ഷനുകൾക്ക് പകരം സർവർ സർട്ടിഫിക്കറ്റോ ഐഡന്റിഫയറോ ചോദിക്കുന്നു. അക്കൗണ്ട് പേര് രണ്ട് ക്രമീകരണങ്ങളിലും ഒന്നുതന്നെ, അതിനാൽ നിങ്ങളുടെ പക്കൽ ഏതാണെന്ന് അതിന് പറയാനാവില്ല. ഓപ്പറേറ്റർ പിന്തുണയ്ക്കുന്ന പ്രോട്ടോക്കോളുകളുടെ പട്ടിക മാത്രമാണ് അത് തീരുമാനിക്കുന്നത്.

TLS അടിസ്ഥാനമാക്കിയ VPN മൂന്നാമത്തെ ക്രമീകരണം കൂട്ടിച്ചേർക്കുന്നു, അതിന്റെ സ്വന്തം ഉപയോക്തൃനാമ, പാസ്വേഡ് ഫീൽഡുകളോടെ, കൈമാറ്റത്തിൽ എവിടെയും MS-CHAPv2 ഇല്ലാതെ. അതുകൊണ്ട് പാസ്വേഡ് പെട്ടി കാണുന്നത് അതിന് പിന്നിലെ പ്രോട്ടോക്കോളിന്റെ തെളിവല്ല, ഫോം പരിചിതമായി തോന്നാൻ വേണ്ടി നിർമ്മിച്ചതാണ്. പ്രോട്ടോക്കോൾ ക്ലയന്റ് വിൻഡോയുടെ ആകൃതിയിൽ നിന്നല്ല, സർവർ ഡോക്യുമെന്റേഷനിൽ നിന്ന് സ്ഥിരീകരിക്കുക.

നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ വേണ്ട ഉത്തരങ്ങൾ

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

ആദ്യത്തെ മൂന്ന് നിങ്ങൾക്ക് പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ ലഭിക്കുമോ എന്ന് തീരുമാനിക്കുന്നു. അവസാനത്തെ മൂന്ന് ആ പ്രൊഫൈൽ ജോലിക്ക് വേണ്ടത് ചെയ്യുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. ഉത്തരം ടിക്കറ്റിനോട് ചേർത്ത് സൂക്ഷിക്കുക, അടുത്തയാളും അതേ ആറ് ചോദ്യങ്ങൾ ചോദിക്കും. ഉത്തരം ഇല്ലാത്തിടത്ത് ആ വിടവിനെ ഓപ്പറേറ്റർ ഇനിയും എടുക്കാത്ത തീരുമാനമായി കാണുക, നിങ്ങൾക്ക് അനുമാനിക്കാവുന്ന ഒന്നായല്ല.

ഗേറ്റ്വേ പരിശോധന അയഞ്ഞതാക്കരുത്

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

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

പ്രൊഫൈൽ യോജിപ്പിക്കുക, പിന്നെ ഓരോ ഘട്ടവും തെളിയിക്കുക

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

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