SSTP ആദ്യം സർവറിനെയും പിന്നീട് ഉപയോക്താവിനെയും പ്രാമാണീകരിക്കുന്നു

SSTP ക്ലയന്റിന് TLS പൂർത്തിയാക്കിയ ശേഷവും ഒരു സെക്കൻഡ് കഴിഞ്ഞ് ഉപയോക്താവിനെ നിരസിക്കാം. ഈ ക്രമം ഒരു ബഗ് അല്ല, ഇത് പ്രോട്ടോക്കോൾ സ്റ്റാക്ക് ആണ്: ആദ്യം ഗതാഗത സുരക്ഷ, പിന്നീട് ഉപയോക്തൃ പ്രാമാണീകരണം. രണ്ട് ഘട്ടങ്ങളും വ്യത്യസ്ത സന്ദേശങ്ങളോടെ പരാജയപ്പെടുന്നതിനാൽ, അവയ്ക്ക് വ്യത്യസ്ത പരിഹാരങ്ങളും ആവശ്യമാണ്. ഏത് ഘട്ടമാണ് പിശക് സൃഷ്ടിച്ചതെന്ന് വായിക്കുന്നതാണ് രോഗനിർണയത്തിന്റെ ഭൂരിഭാഗവും.

വിശ്വസ്ത സർട്ടിഫിക്കറ്റ് എൻഡ്‌പോയിന്റ് തെളിയിക്കുന്നു; അക്കൗണ്ടിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

TLS ഹാൻഡ്‌ഷേക്ക് എന്താണ് സ്ഥാപിക്കുന്നത്

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

അതുകൊണ്ട് ലോഗിൻ പ്രോംപ്റ്റിലെത്താൻ സർട്ടിഫിക്കറ്റ് പരിശോധനകൾ നീക്കം ചെയ്യുന്നത് തെറ്റായ പരിഹാരമാണ്. നിങ്ങൾക്ക് പരിശോധിക്കാൻ കഴിയാത്ത ബന്ധത്തിൽ ലോഗിൻ പ്രോംപ്റ്റ് ലഭിക്കും. സർട്ടിഫിക്കറ്റ് പിശക് ഹോസ്റ്റ്നാമം, ക്ലോക്ക്, ചെയിൻ അല്ലെങ്കിൽ ട്രസ്റ്റ് കോൺഫിഗറേഷനുമായി ബന്ധപ്പെട്ടതാണ്.

SSTP-യും PPP-യും മുകളിൽ എന്ത് ചേർക്കുന്നു

SSTP HTTPS-ന് മുകളിൽ പ്രവർത്തിക്കുകയും ഉള്ളിൽ PPP വഹിക്കുകയും ചെയ്യുന്നു, ബന്ധത്തിന് ചുറ്റുമുള്ള സ്വന്തം നിയന്ത്രണ കൈമാറ്റത്തോടെ. തുടർന്ന് PPP അതിന്റെ ലിങ്ക്, പ്രാമാണീകരണ ഘട്ടങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നു, പ്രാമാണീകരണ രീതി സർവർ നയത്തെയും ക്ലയന്റ് കഴിവിനെയും ആശ്രയിച്ചിരിക്കുന്നു. PAP, CHAP, MS-CHAPv2, EAP എന്നിവയെല്ലാം വളരെ വ്യത്യസ്ത സ്വഭാവങ്ങളുള്ള PPP പ്രാമാണീകരണ ഓപ്ഷനുകളാണ്. VPN-ന്റെ ഉപയോക്തൃ പരിശോധന ആ PPP ഘട്ടമാണ്, അതിനടിയിലുള്ള TLS പാളിയല്ല.

അതുകൊണ്ട് ഉപയോക്താവിനെ നിരസിക്കുന്നത് ക്രെഡൻഷ്യലുകൾ, അക്കൗണ്ട് നിയന്ത്രണം അല്ലെങ്കിൽ രീതി പൊരുത്തക്കേട് എന്നിവ അർത്ഥമാക്കാം.

സർവർ വശത്തെ കാരണം പ്രൊഫൈലിലെ ഓരോ രഹസ്യവും പുനഃസജ്ജമാക്കുന്നതിനേക്കാൾ വളരെ ഉപയോഗപ്രദമാണ്. അക്കൗണ്ട് പ്രവർത്തനരഹിതമായ സംഭവവും രീതി ചർച്ചയുടെ പരാജയവും ക്ലയന്റിൽ സമാനമായി തോന്നുമെങ്കിലും സർവറിൽ അവയ്ക്ക് പൊതുവായി ഒന്നുമില്ല.

പിശക് ഘട്ടവുമായി ചേർക്കുക

ബന്ധം TLS-ലെത്തുന്നുണ്ടോ, തുടർന്ന് SSTP HTTP കൈമാറ്റം, തുടർന്ന് PPP ഘട്ടം എന്നിവ പരിശോധിക്കുക. വീണ്ടും ശ്രമങ്ങൾക്കിടയിൽ ലോഗുകളുടെ സമയമുദ്രകൾ വിന്യസിച്ച് നിർത്തുക, അങ്ങനെ മുൻ പരാജയം പിന്നീടുള്ള വിജയവുമായി കൂടിക്കാഴ്ച ചെയ്യില്ല. ഒരു ജാലകത്തിൽ രണ്ട് ശ്രമങ്ങൾ രേഖപ്പെടുത്തുന്ന ക്ലയന്റ് അല്ലാത്തപക്ഷം താൻ എത്തിയ അവസാന ഘട്ടത്തിൽ പരാജയപ്പെട്ടതായി തോന്നും. അവസാന വരിയല്ല, ആദ്യത്തെ പ്രസക്തമായ പിശക് വായിക്കുക.

അതേ വിന്യാസം സർവർ വശത്തും പ്രധാനമാണ്, അവിടെ പ്രാമാണീകരണ രേഖയും ഗതാഗത ലോഗും പലപ്പോഴും വ്യത്യസ്ത ക്ലോക്കുകളുള്ള വേറിട്ട ഫയലുകളാണ്. രണ്ട് മിനിറ്റ് വ്യത്യാസം വ്യക്തമായ ഒരു കാരണത്തെ അസാധ്യമായി തോന്നിപ്പിക്കാൻ മതി.

ലോഗിൻ കഴിഞ്ഞും അധികാരപ്പെടുത്തൽ വേറിട്ടതാണ്

വിജയകരമായ ലോഗിൻ എല്ലാ സ്വകാര്യ വിഭവങ്ങളും നൽകുന്നില്ല. റൂട്ടുകൾ എത്തിച്ചേരാവുന്നത് നിർണ്ണയിക്കുന്നു, DNS എന്ത് പരിഹരിക്കപ്പെടുന്നു എന്ന് നിർണ്ണയിക്കുന്നു, ഓരോ സേവനവും ഇപ്പോഴും അതിന്റെ സ്വന്തം അനുമതികൾ പ്രയോഗിക്കുന്നു. ബന്ധിപ്പിച്ചതായി കാണിക്കുന്ന സെഷൻ ടണലിനെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്, ഫയൽ പങ്കിടലിനെക്കുറിച്ചല്ല. ഉപയോക്താവിന് ബന്ധിപ്പിക്കാൻ കഴിയുകയും ഒരു ഹോസ്റ്റിൽ എത്തിച്ചേരാൻ കഴിയാതിരിക്കുകയും ചെയ്താൽ, ടണൽ ഘട്ടം ഇതിനകം അവസാനിച്ചു.

ഹാൻഡ്‌ഷേക്ക് കാണിച്ച അതേ പാളിവിന്യാസമാണിത്, ഒരു തലം മുകളിൽ.

അക്കൗണ്ട് വീണ്ടെടുക്കൽ ഓപ്പറേറ്റർ പിന്തുണയ്ക്കുന്ന പ്രക്രിയയിൽ നിലനിർത്തുക, വ്യക്തമായ ഉപയോക്തൃ നിരസിക്കലിനോട് പ്രതികരണമായി ഗതാഗത ക്രമീകരണങ്ങൾ മാറ്റുന്നതിന് പകരം. പ്രവർത്തനരഹിതമായ അക്കൗണ്ട് ശരിയാക്കാൻ ഗതാഗതം മാറ്റുന്നത്, അക്കൗണ്ട് ബന്ധമില്ലാത്ത കാരണത്താൽ വീണ്ടും പ്രവർത്തനക്ഷമമാകുമ്പോൾ ഫലപ്രദമായി തോന്നുന്ന തരം പരിഹാരമാണ്.