SSTP കാലഹരണമോ സർട്ടിഫിക്കറ്റ് പിശകോ: രണ്ടും എങ്ങനെ വേർതിരിക്കാം

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

രണ്ട് പരാജയങ്ങൾ, രണ്ട് വ്യത്യസ്ത കൈമാറ്റങ്ങൾ

SSTP HTTPS രൂപത്തിലുള്ള സെഷനുള്ളിൽ ഒരു ടണൽ വഹിക്കുന്നു, അതുകൊണ്ട് 443 അല്ലാതെ ഒന്നും അനുവദിക്കാത്ത നെറ്റ്വർക്കുകളിലും അത് നിലനിൽക്കുന്നു. ക്ലൈന്റ് TLS ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കുന്നു, പ്രോട്ടോക്കോളിന് സവിശേഷമായ രീതിയിൽ HTTP അഭ്യർത്ഥന അയക്കുന്നു, പിന്നീട് ടണൽ ആ സ്ട്രീമിനുള്ളിൽ പ്രവർത്തിക്കുന്നു. ആ ഘട്ടങ്ങളിൽ ഏതിലും പരാജയം കണക്ഷൻ നിർത്തുന്നു, കൂടാതെ അവസാനത്തെ ഘട്ടങ്ങൾ മാത്രമാണ് ലോഗിൻ വിവരങ്ങളുമായി ബന്ധപ്പെടുന്നത്.

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

ലോഗ് വരി സാധാരണയായി മൂന്നിൽ ഏതിലാണ് നിങ്ങളെന്ന് പറയുന്നു, അതിനാൽ ആദ്യ മാറ്റത്തിന് മുൻപ് അത് രേഖപ്പെടുത്തുന്നത് ഉചിതമാണ്.

കാലഹരണം എന്നാൽ ഒരു ഘട്ടം ഒരിക്കലും പൂർത്തിയായില്ല

പേര് നിർണ്ണയത്തിലും TCP ലഭ്യതയിലും തുടങ്ങുക, കാരണം അവിടത്തെ കാലഹരണം പിന്നീടുള്ള കാലഹരണത്തിന് സമാനമായി തോന്നുന്നു. 443 തുറന്നിരിക്കുന്നു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന പോർട്ട് പരിശോധിനി ഒരു ശ്രോതാവ് കണക്ഷൻ സ്വീകരിച്ചു എന്ന് മാത്രം തെളിയിക്കുന്നു, അതിൽ കൂടുതലൊന്നുമില്ല.

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

പങ്കാളിയിൽ നിന്നുള്ള ഏതെങ്കിലും മറുപടിക്ക് മുൻപുള്ള കാലഹരണം അക്കൗണ്ടിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അപ്പോൾ പാസ്വേഡ് മാറ്റുന്നത് ഒരു ചരം മാത്രം കൂട്ടിച്ചേർക്കുന്നു.

സർട്ടിഫിക്കറ്റ് പിശക് എന്നാൽ ഐഡന്റിറ്റി നിരസിക്കപ്പെട്ടു

ഇവിടെ സെർവർ യഥാർത്ഥത്തിൽ മറുപടി നൽകി, അതിനാൽ നെറ്റ്വർക്ക് പ്രവർത്തിക്കുന്നു, ചോദ്യം ഐഡന്റിറ്റിയിലേക്ക് നീങ്ങുന്നു. ക്ലൈന്റ് ഡയൽ ചെയ്യുന്ന പേരിനെ സർട്ടിഫിക്കറ്റ് യഥാർത്ഥത്തിൽ അവകാശപ്പെടുന്ന പേരുകളുമായി താരതമ്യം ചെയ്യുക, പിന്നീട് സാധുതാ തീയതികളും ഇഷ്യു ചെയിൻ ശൃംഖലയും പരിശോധിക്കുക.

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

വിജയകരമായ TLS ഘട്ടം കടന്നുപോയതിന് ശേഷം അതേപടി നിലനിർത്തുക, കാരണം പിന്നീട് അത് പഴയപടിയാക്കുന്നത് ഏത് മാറ്റമാണ് ടണൽ യഥാർത്ഥത്തിൽ ശരിയാക്കിയതെന്ന് മറയ്ക്കുന്നു.

രണ്ടും ആശയക്കുഴപ്പത്തിലാകുന്നിടം

രണ്ട് പരാജയങ്ങളും ഉയരാത്ത കണക്ഷനായി പ്രത്യക്ഷപ്പെടുന്നു, രണ്ടും ഉപയോക്താവ് അസംബന്ധമായ എന്തോ മാറ്റിയതിന് ശേഷം വരുന്നു. ആ യാദൃച്ഛികതയാണ് തെറ്റായ അറ്റകുറ്റപ്പണിയെ കുറച്ച് സമയം വിശ്വസനീയമായി തോന്നിപ്പിക്കുന്നത്.

രണ്ട് ശീലങ്ങൾ അവയെ വേർതിരിക്കുന്നു. കോൺഫിഗറേഷൻ തൊടുന്നതിന് മുൻപ് ക്ലൈന്റ് ലോഗ് രേഖപ്പെടുത്തുക, ആദ്യ അവസ്ഥ നിലനിർത്താൻ. ഓരോ ശ്രമത്തിലും ഒരു പാളി മാറ്റുക, അടുത്ത ഫലം അറിയപ്പെടുന്ന ചരത്തിന്റേതാകാൻ. പോർട്ട് പരിശോധിനിയും ബ്രൗസറും പൂർണ്ണ ക്രമമല്ല, ഭാഗിക നിരീക്ഷണങ്ങളാണ്, ഒന്നും ക്ലൈന്റിന്റെ സ്വന്തം റിപ്പോർട്ടിന് പകരമാകുന്നില്ല. രണ്ട് ശീലങ്ങൾക്കും ചെലവില്ല, രണ്ടും അന്വേഷണം ചുരുക്കുന്നു.

സർട്ടിഫിക്കറ്റ് ചോദ്യവും ലഭ്യതാ ചോദ്യവും ഒരു കാരണത്താൽ വെവ്വേറെ രേഖപ്പെടുത്തിയിരിക്കുന്നു.

യഥാർത്ഥ ക്ലൈന്റിൽ വീണ്ടും പരീക്ഷിക്കുക, പിന്നീട് അകത്തേക്ക് നീങ്ങുക

നിർദ്ദിഷ്ട തിരുത്ത് സ്ഥാനത്തായാൽ ബ്രൗസർ ടാബിലല്ല, യഥാർത്ഥ SSTP ക്ലൈന്റിലും യഥാർത്ഥ പ്രൊഫൈലിലും വീണ്ടും ശ്രമിക്കുക.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

സെഷൻ കണക്ട് ചെയ്തിട്ടും വിഭവങ്ങൾ പരാജയപ്പെടുന്നെങ്കിൽ, ടണൽ ഇനി സംശയാസ്പദമല്ല: റൂട്ടിംഗ്, DNS, സേവന പ്രവേശനം എന്നിവയിലേക്ക് നീങ്ങുക. അത് വേറെ തെളിവുകളുള്ള വേറെ അന്വേഷണമാണ്. പ്രവർത്തിക്കുന്ന TLS, പ്രാമാണീകരണ ഘട്ടങ്ങൾ നിലനിർത്തുന്നത് അത് ആദ്യത്തേതിന്റെ ആവർത്തനമാകുന്നത് തടയുന്നു. പരാജയപ്പെട്ട ഘട്ടം ടിക്കറ്റിൽ എഴുതുക, അല്ലെങ്കിൽ അടുത്ത വ്യക്തി വീണ്ടും മുകളിൽ നിന്ന് തുടങ്ങും.