SSTP ഉം IKEv2 ഉം വ്യത്യസ്ത RRAS സർട്ടിഫിക്കറ്റ് നിയന്ത്രണങ്ങൾ ഉപയോഗിക്കുന്നു

നിങ്ങൾ «VPN സർട്ടിഫിക്കറ്റ്» മാറ്റുകയാണെങ്കിൽ തെറ്റായ സേവനം മാറ്റിയേക്കാം. RRAS കുറഞ്ഞത് മൂന്ന് സർട്ടിഫിക്കറ്റ് നിയന്ത്രണങ്ങൾ സൂക്ഷിക്കുന്നു, അവയിൽ ഓരോന്നും വേറിട്ട പ്രോട്ടോക്കോളിനും വേറിട്ട കണക്ഷൻ റോളിനും ഉള്ളതാണ്. ആദ്യം പ്രോട്ടോക്കോളിന് പേരിടുന്നത് അപകടകരമായ ഊഹത്തെ ഒറ്റ തിരിച്ചുമാറ്റാവുന്ന ബൈൻഡിംഗ് മാറ്റമാക്കി മാറ്റുന്നു. താഴെയുള്ളതെല്ലാം ആ ഒരു വാക്യത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

സർട്ടിഫിക്കറ്റിന് മുൻപ് പ്രോട്ടോക്കോൾ പേരിടുക

SSTP ശ്രോതാവ് HTTPS പോലെ പെരുമാറുന്ന ക്ലയന്റിന് TLS സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു. വരുന്ന സൈറ്റ്-ടു-സൈറ്റ് IKEv2 കണക്ഷൻ സെർവറിന്റെ ഐഡന്റിറ്റി പ്രഖ്യാപിക്കുകയും സമപീരുകളുടെ സർട്ടിഫിക്കറ്റുകൾ വിശ്വസനീയമായ റൂട്ടിനെതിരെ സാധൂകരിക്കുകയും ചെയ്യുന്നു. ഓരോ ഇന്റർഫേസിനുമുള്ള സൈറ്റ്-ടു-സൈറ്റ് നിർവചനം സ്വന്തം മെഷീൻ ഐഡന്റിറ്റി വഹിക്കുന്നു.

ഇവ മൂന്ന് പരിധികളുള്ള മൂന്ന് നിയന്ത്രണങ്ങളാണ്. അവ കൂട്ടിക്കലർത്തുന്നത് ഒരു പ്രോട്ടോക്കോളിൽ പ്രവർത്തിക്കുന്നതായി തോന്നുകയും മറ്റൊന്നിൽ യാതൊരു ഫലവുമില്ലാതിരിക്കുകയും ചെയ്യുന്ന മാറ്റം സൃഷ്ടിക്കുന്നു, ഇത് വ്യക്തമായ പരാജയത്തെക്കാൾ മോശമാണ്. എന്തെങ്കിലും തൊടുന്നതിന് മുൻപ് ഏത് പ്രോട്ടോക്കോൾ പരാജയപ്പെട്ടു, ഏത് വശം സർട്ടിഫിക്കറ്റ് അവതരിപ്പിച്ചു, ഏത് വശം അത് നിരസിച്ചു എന്ന് എഴുതിവയ്ക്കുക.

SSTP ഒരു HTTPS ബൈൻഡിംഗാണ്

പിന്തുണയ്ക്കുന്ന Remote Access വിന്യാസങ്ങളിൽ Set-RemoteAccess SSTP കണക്റ്റിവിറ്റിക്കും HTTPS-ബന്ധിത DirectAccess റോളിനും ഉപയോഗിക്കുന്ന SslCertificate പരാമീറ്റർ വെളിപ്പെടുത്തുന്നു.

അതിന്റെ സാധൂകരണ, വിന്യാസ പരിധി Remote Access കോൺഫിഗറേഷനെ പിന്തുടരുന്നു, അതിനാൽ ഒരു ബൈൻഡിംഗ് മാറ്റം ഒന്നിലധികം കണക്ഷനുകളിലേക്കോ നോഡുകളിലേക്കോ എത്താം. ലോഡ് ബാലൻസ്ഡ് വിന്യാസത്തിൽ ഈ പരിധി കോൺഫിഗറേഷൻ ഉൾക്കൊള്ളുന്ന ഓരോ നോഡും ഉൾപ്പെടുത്തുന്നു. ഒരു നോഡ് മാറ്റി ഒരു ക്ലയന്റ് പരിശോധിക്കുന്നത് ബാക്കിയുള്ളവ പഴയ ഇല അവതരിപ്പിച്ചുകൊണ്ടിരിക്കാൻ വിടുന്നു, ഇതാണ് അറ്റകുറ്റപ്പണി ജാലകത്തിൽ നിന്ന് രക്ഷപ്പെടുന്ന പകുതി-മാറ്റം.

അപ്ഡേറ്റിന് മുൻപ് പ്രതീക്ഷിക്കുന്ന സേവന നാമം, ചെയിൻ, സാധുത, ഉദ്ദേശിച്ച ഉപയോഗം, സ്വകാര്യ കീയുടെ ലഭ്യത എന്നിവ പരിശോധിക്കുക. സർട്ടിഫിക്കറ്റ് ക്ലയന്റ് പരിശോധിക്കുന്ന പേരുമായി പൊരുത്തപ്പെടണം, അഡാപ്റ്റർ ലേബൽ ആ പേരല്ല.

വരുന്ന IKEv2-ന് സ്വന്തം പരാമീറ്ററുണ്ട്

Set-VpnAuthProtocol വരുന്ന സൈറ്റ്-ടു-സൈറ്റ് IKEv2 പ്രാമാണീകരണം കോൺഫിഗർ ചെയ്യുന്നു, CertificateAdvertised ടണൽ പ്രാമാണീകരണ മോഡ് അവ ഉപയോഗിക്കുമ്പോൾ സർട്ടിഫിക്കറ്റ് നൽകുന്നു. ഇത് ഹോസ്റ്റിലെ ഏതെങ്കിലും സെർവർ സർട്ടിഫിക്കറ്റ് തിരഞ്ഞെടുക്കാനുള്ള പൊതുവായ കമാൻഡല്ല.

രണ്ട് വസ്തുക്കൾ വേർതിരിച്ച് വയ്ക്കുക: സെർവർ സ്വന്തം ഐഡന്റിറ്റിയായി അവതരിപ്പിക്കുന്ന ഇല, സമപീരുകളുടെ സർട്ടിഫിക്കറ്റുകൾ സ്വീകരിക്കാൻ ഉപയോഗിക്കുന്ന റൂട്ട്. ഏത് ഇഷ്യൂവറെ വിശ്വസിക്കണം എന്ന തിരഞ്ഞെടുപ്പ് സെർവർ ഏത് ഇല അവതരിപ്പിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

വ്യക്തിഗത സൈറ്റ്-ടു-സൈറ്റ് ഇന്റർഫേസിന്റെ ഐഡന്റിറ്റി Set-VpnS2SInterface വഴി സജ്ജീകരിക്കുന്നു. രണ്ടും ഒരേ മെഷീനിലെ ഒരേ സ്റ്റോറിലാണെങ്കിലും ഇത് സ്വയമേവ SSTP സർട്ടിഫിക്കറ്റല്ല.

ആദ്യം സ്ഥാനാർത്ഥി പരിശോധിക്കുക

പ്രാദേശിക മെഷീന്റെ സ്റ്റോറിന്റെ കേന്ദ്രീകൃത കാഴ്ച ഒന്നും സ്വകാര്യമായി കയറ്റുമതി ചെയ്യാതെ പൊതു മെറ്റാഡാറ്റ കാണിക്കുന്നു:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

ആ പട്ടിക തുടക്കമാണ്, അനുയോജ്യതാ പരിശോധനയല്ല. നിങ്ങൾ കോൺഫിഗർ ചെയ്യുന്ന പ്രോട്ടോക്കോളിനുള്ള SAN എൻട്രികൾ, വിപുലീകൃത കീ ഉപയോഗങ്ങൾ, ചെയിൻ, സേവന അക്കൗണ്ടിന്റെ സ്വകാര്യ കീ പ്രവേശനം എന്നിവ പരിശോധിക്കുക.

ബന്ധമില്ലാത്ത ക്ലൗഡ് ക്ലയന്റ് ഐഡന്റിറ്റിക്കായി ഇൻസ്റ്റാൾ ചെയ്ത സർട്ടിഫിക്കറ്റ് അതേ സ്റ്റോറിൽ കാണുന്നു എന്ന കാരണത്താൽ മാത്രം അനുയോജ്യമല്ല. ദൃശ്യത അനുയോജ്യതയല്ല, സ്ക്രീൻഷോട്ടിലെ വിരലടയാളം സേവന അക്കൗണ്ടിന് കീ വായിക്കാനാകുമോ എന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ആ പ്രവേശനം വ്യക്തമായി പരിശോധിക്കുക, കാരണം കീയുടെ അനുമതി ഇല്ലാത്തത് സേവനം പുനരാരംഭിച്ച് സർട്ടിഫിക്കറ്റ് ഉപയോഗിക്കാൻ ശ്രമിക്കുമ്പോൾ മാത്രമേ പുറത്തുവരൂ.

നിലവിലെ ബൈൻഡിംഗ് രേഖപ്പെടുത്തി, മാറ്റുന്നതിന് മുൻപ് ഹോസ്റ്റ് ഇപ്പോഴും മറ്റൊരു വഴിക്ക് എത്താനാകുമെന്ന് ഉറപ്പാക്കുക. വീണ്ടെടുപ്പ് പാത മാറ്റത്തിന്റെ ഭാഗമാണ്, തുടർന്ന് വരുന്ന സംഭവത്തിന്റെ ഭാഗമല്ല.

പുതുക്കൽ സജീവമാക്കലല്ല

സർട്ടിഫിക്കറ്റ് വീണ്ടും നൽകുന്നത് പ്രവർത്തിക്കുന്ന സേവനത്തിനായി അത് തിരഞ്ഞെടുക്കുന്നതിൽ നിന്ന് വ്യത്യസ്ത പ്രവൃത്തിയാണ്. പുതിയ ഇല ഉദ്ദേശിച്ച DNS ഐഡന്റിറ്റി നിലനിർത്തുകയും എന്നിട്ടും വ്യത്യസ്ത വിരലടയാളം വഹിക്കുകയും ചെയ്യാം, അതിനാൽ ബൈൻഡിംഗ് പുതുക്കുന്നതുവരെ ഒന്നും അതിലേക്ക് ചൂണ്ടുന്നില്ല. പുതുക്കൽ വസ്തുവിനെ മാറ്റുന്നു; സജീവമാക്കൽ അതിലേക്കുള്ള റഫറൻസിനെ മാറ്റുന്നു. ഇവ രണ്ടും കൂട്ടിക്കലർത്തുന്നതാണ് ശരിയായി പുതുക്കിയ സർട്ടിഫിക്കറ്റ് ആഴ്ചകളോളം ഉപയോഗിക്കാതെ കിടക്കാൻ കാരണം.

പിന്തുണയ്ക്കുന്ന മാറ്റം അനുയോജ്യമായ ജാലകത്തിൽ, രേഖപ്പെടുത്തിയ പുനരാരംഭം ഉൾപ്പെടെ പ്രയോഗിക്കുക, തുടർന്ന് സർട്ടിഫിക്കറ്റ് ഉദ്ദേശിച്ച പ്രോട്ടോക്കോളിന്റെ പുതിയ കണക്ഷനിൽ നിന്ന് പരിശോധിക്കുക. കാഷ് ചെയ്ത ക്ലയന്റ് സെഷൻ ഇപ്പോഴും പഴയ ഇല കാണിച്ച് ശരിയായ മാറ്റത്തെ തകർന്നതായി തോന്നിപ്പിക്കാം.

മുൻ സർട്ടിഫിക്കറ്റ് ആ പരിശോധന കടന്നതിന് ശേഷം മാത്രം സാധാരണ നടപടിക്രമത്തിലൂടെ ഒഴിവാക്കുക. Set-RemoteAccess റഫറൻസ് SSL പരാമീറ്ററിന്റെ പരിധി, ലോഡ് ബാലൻസ്ഡ് വിന്യാസങ്ങളിലെ അതിന്റെ ഫലം ഉൾപ്പെടെ രേഖപ്പെടുത്തുന്നു, ബൈൻഡിംഗ് മാറ്റത്തിന് മുൻപ് വായിക്കാൻ യോഗ്യമായ ഭാഗം അതാണ്.