നേറ്റീവ് Windows IKEv2-ൽ PSK ഫീൽഡ് ഒട്ടുമില്ലാത്തതിന്റെ കാരണം

ഗേറ്റ്‌വേയുടെ ഡോക്യുമെന്റേഷൻ പറയുന്നത് മുൻകൂട്ടി പങ്കിട്ട കീ ക്ലയന്റിൽ നൽകണം എന്നാണ്, പക്ഷേ Windows പ്രൊഫൈലിൽ അതിന് ഫീൽഡില്ല. ഈ വിടവ് പാസ്‌വേഡ് ബോക്സിൽ കീ ടൈപ്പ് ചെയ്ത് ഒഴിവാക്കാവുന്ന ബഗ്ഗല്ല. പ്രോട്ടോക്കോളിന് എന്ത് ചെയ്യാനാകും, ഒരു പ്രത്യേക നടപ്പാക്കൽ എന്ത് വാഗ്ദാനം ചെയ്യുന്നു എന്നതിനിടയിലെ വ്യത്യാസമാണിത്.

പ്രോട്ടോക്കോൾ കഴിവ് ക്ലയന്റ് പിന്തുണയല്ല

IKEv2 സ്പെസിഫിക്കേഷനിൽ പങ്കിട്ട കീ പ്രാമാണീകരണം ഉൾപ്പെടുന്നു, അതിനാൽ ഗേറ്റ്‌വേയെ അതിനായി നിയമാനുസൃതമായി കോൺഫിഗർ ചെയ്യാം. നേറ്റീവ് Windows റിമോട്ട് ആക്സസ് പ്രൊഫൈൽ പകരം സർട്ടിഫിക്കറ്റ്, EAP ക്രമീകരണങ്ങൾ രേഖപ്പെടുത്തുന്നു, പ്രോട്ടോക്കോൾ കഴിവ് ക്ലയന്റിന് ഒരിക്കലും ഉണ്ടായിരുന്നില്ലാത്ത ഫീൽഡോ പാരാമീറ്ററോ രജിസ്ട്രി മൂല്യമോ സൃഷ്ടിക്കുന്നില്ല.

ആളുകൾ സാധാരണയായി VPN കണക്ഷൻ ചേർക്കാനുള്ള PowerShell റഫറൻസ് എന്നതിൽ എത്തുന്നു, അവിടെ L2TP ക്രമീകരണത്തിന് L2tpPsk കാണിക്കുന്നു. ആ പാരാമീറ്റർ L2TP-ന്റേതാണ്, പൊതുവായ IKEv2 രഹസ്യമല്ല. അൽഗോരിതം തിരഞ്ഞെടുപ്പ് ക്രമീകരണങ്ങൾ സംരക്ഷണ പാരാമീറ്ററുകൾ തിരഞ്ഞെടുക്കുന്നു, അത് മൂന്നാമത്തെ, ബന്ധമില്ലാത്ത കാര്യമാണ്. Windows Server-ന്റെ റൂട്ടിംഗ് റോളും അതേ ഒബ്ജക്റ്റല്ല. സർവർ ഇന്റർഫേസിൽ ഡെസ്ക്ടോപ്പ് ക്ലയന്റ് പ്രൊഫൈലിനില്ലാത്ത കോൺഫിഗറേഷൻ നിയന്ത്രണങ്ങൾ ഉണ്ടാകാം, സർവർ ക്രമീകരണം വർക്ക്സ്റ്റേഷൻ പ്രൊഫൈലിലേക്ക് പകർത്തുന്നത് ആ കഴിവ് പുനഃസൃഷ്ടിക്കുന്നില്ല.

സർട്ടിഫിക്കറ്റ്, EAP അല്ലെങ്കിൽ L2TP തിരഞ്ഞെടുക്കുക

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

ഉപയോക്തൃ ക്രെഡൻഷ്യലുള്ള EAP ഈ ക്ലയന്റിലെ മറ്റൊരു പിന്തുണയുള്ള വഴിയാണ്, അത് തീരുമാനം ഒരു ഐഡന്റിറ്റി പ്രൊവൈഡറിലേക്ക് മാറ്റുന്നു. അതിന് സ്വന്തം ആശ്രിതത്വങ്ങളുമുണ്ട്, കാരണം EAP രീതി, സർവർ സർട്ടിഫിക്കറ്റ്, ആ സർട്ടിഫിക്കറ്റിലുള്ള ക്ലയന്റിന്റെ വിശ്വാസം എല്ലാം ഒത്തുപോകണം. പരിചിതമായ ഒരു ഫീൽഡ് ലഭിക്കാൻ മാത്രം L2TP/IPsec-ലേക്ക് മാറുന്നത് പ്രോട്ടോക്കോൾ സ്റ്റാക്ക് മാറ്റുന്നു. രേഖപ്പെടുത്തിയ കാരണമുള്ള പിന്തുണയുള്ള തിരഞ്ഞെടുപ്പാകുമ്പോൾ അത് സ്വീകാര്യമാണ്, ആരോ കീ ടൈപ്പ് ചെയ്യാൻ ഒരു ബോക്സ് അന്വേഷിച്ചതുകൊണ്ട് സംഭവിക്കുമ്പോൾ അത് മോശം ഫലമാണ്.

ഗേറ്റ്‌വേ എന്ത് സ്വീകരിക്കുമെന്ന് പരിശോധിക്കുക

ഉൽപ്പന്നം പൊതുവായി പിന്തുണയ്ക്കുന്നവയല്ല, റിമോട്ട് ആക്സസ് സേവനം ഇന്ന് നൽകുന്ന പ്രാമാണീകരണ രീതികൾ ഏതെന്ന് ഓപ്പറേറ്ററിനോട് ചോദിക്കുക. PSK മാത്രത്തിനായി കോൺഫിഗർ ചെയ്ത IKEv2 സേവനം ക്ലയന്റ് അത് ഇഷ്ടപ്പെടുന്നു എന്ന കാരണത്താൽ സർട്ടിഫിക്കറ്റ് സ്വീകരിക്കില്ല.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

പ്രൊഫൈലിന്റെ പ്രാമാണീകരണ രീതിയും സർട്ടിഫിക്കറ്റ് സ്റ്റോറും ഒരുമിച്ച് വായിക്കുക. പിന്നിൽ ഉപയോഗയോഗ്യമായ സർട്ടിഫിക്കറ്റില്ലാത്ത EAP-ലേക്ക് സെറ്റ് ചെയ്ത പ്രൊഫൈൽ സർവർ പ്രശ്നം പോലെ തോന്നുന്ന രീതിയിൽ പരാജയപ്പെടുന്നു.

PSK മാത്രമേ ലഭ്യമുള്ളൂ എന്നാണ് ഉത്തരമെങ്കിൽ, സത്യസന്ധമായ ഓപ്ഷനുകൾ അത് പിന്തുണയ്ക്കുന്ന അംഗീകൃത ക്ലയന്റ് അല്ലെങ്കിൽ ഗേറ്റ്‌വേയുടെ പ്രാമാണീകരണ രൂപകൽപ്പനയിലെ മാറ്റമാണ്. രണ്ടും പ്രാദേശിക പരിഹാരമല്ല, വിപരീതം അഭിനയിക്കുന്നത് കോൺഫിഗർ ചെയ്ത വ്യക്തിക്ക് മാത്രം പുനഃസൃഷ്ടിക്കാനാകുന്ന ബന്ധം സൃഷ്ടിക്കുന്നു.

തീരുമാനവും രഹസ്യങ്ങളും രേഖപ്പെടുത്തുക

തിരഞ്ഞെടുത്ത രീതി, വിശ്വാസ ആങ്കർ, അതിന് യോജിക്കുന്ന ഐഡന്റിറ്റി, മാറ്റം അംഗീകരിച്ച വ്യക്തി എന്നിവ എഴുതുക. ആ രേഖയാണ് സംഭവ അവലോകനത്തിന് വേണ്ടത്, അത് അടുത്ത എൻജിനീയറെ അതേ അന്ധമായ വഴി വീണ്ടും കണ്ടെത്തുന്നതിൽ നിന്ന് തടയുന്നു.

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