SSTP എന്നത് HTTPS-ന് മുകളിലുള്ള PPP ആണ്, പോർട്ട് 443-ലെ വെബ് പേജല്ല

SSTP PPP-യെ ഒരു HTTPS കണക്ഷനുള്ളിൽ വഹിക്കുന്നു, അതുകൊണ്ട് നടുവിലുള്ള എന്തിനും അത് വെബ് ട്രാഫിക്ക് പോലെ തോന്നുന്നു. TLS-ഉം HTTP-യും പുറം ചാനൽ സ്ഥാപിക്കുന്നു, തുടർന്ന് SSTP നിയന്ത്രണ സന്ദേശങ്ങൾ ടണൽ തയ്യാറാക്കുന്നു, PPP സെഷന്റെ സ്വഭാവം നൽകുന്നു. അതേ വിലാസത്തിൽ പേജ് ലോഡ് ചെയ്യുന്ന ബ്രൗസർ ആദ്യ ഘട്ടത്തിന്റെ ഒരു ഭാഗം മാത്രമാണ് പൂർത്തിയാക്കിയത്. അതിനെ VPN പരിശോധനയായി കാണുന്നതാണ് പ്രവർത്തിക്കുന്ന പ്രോക്സിയെ പ്രോട്ടോക്കോൾ പൊരുത്തക്കേടിന് കുറ്റപ്പെടുത്തുന്ന വഴി.

നാല് ഘട്ടങ്ങളും ക്രമത്തിൽ കടന്ന് പോകുക, നിങ്ങൾ കാണുന്ന പരാജയം അവയിലൊന്നിൽ വീഴും.

ഘട്ടം 1: TCP-ഉം TLS-ഉം

ക്ലയന്റ് പോർട്ട് 443-ലേക്ക് TCP കണക്ഷൻ തുറന്ന് TLS ഹാൻഡ്ഷേക്ക് ചെയ്യുന്നു. സർട്ടിഫിക്കറ്റ് ശൃംഖല ക്ലയന്റ് കോൺഫിഗർ ചെയ്ത ഹോസ്റ്റ്നാമുമായി പൊരുത്തപ്പെടണം. ഇവിടെ പേരിലെ പൊരുത്തക്കേട് ഏതെങ്കിലും SSTP സന്ദേശം കൈമാറുന്നതിന് മുമ്പേ പരാജയം ഉണ്ടാക്കുന്നു, കൂടാതെ SSTP സ്പെസിഫിക്കേഷൻ ഈ പുറം HTTPS ചാനൽ ഇതിനകം നിലവിലുണ്ടെന്ന് അനുമാനിക്കുന്നു. പിന്നീടുള്ള ഘട്ടങ്ങളിൽ ഒന്നും ഇവിടത്തെ വിശ്വാസ പരാജയത്തിന് പകരം വയ്ക്കാൻ കഴിയില്ല.

ഒരു സാധാരണ വെബ് സർവറിന് ഈ ഘട്ടം പൂർണമായി പൂർത്തിയാക്കി അടുത്തതിൽ പരാജയപ്പെടാം. TLS വിജയം സർട്ടിഫിക്കറ്റിനെക്കുറിച്ചുള്ള തെളിവാണ്, അതിന് പിന്നിലെ പ്രോട്ടോക്കോളിനെക്കുറിച്ചല്ല.

ഘട്ടം 2: HTTPS അഭ്യർത്ഥന

SSTP അതിന്റെ അഭ്യർത്ഥന ഒരു നിർദ്ദിഷ്ട രീതിയിൽ, SSTP_DUPLEX_POST ഉപയോഗിച്ച് നടത്തുന്നു, ഒരു പ്രമാണം തിരികെ നൽകുന്നതിന് പകരം കൈമാറ്റം തുറന്ന് നിർത്തുന്നു. സാധാരണ പേജ് അഭ്യർത്ഥനകൾക്കായി കോൺഫിഗർ ചെയ്ത സർവറിനോ പ്രോക്സിക്കോ കണക്ഷൻ സ്വീകരിച്ച് പിന്നീട് രീതി നിരസിക്കാം. ആ നിരസിക്കലാണ് പോർട്ട് 443 തടയപ്പെട്ടതായി ആളുകൾ സാധാരണ പറയുന്ന പൊരുത്ത സമസ്യ.

സർവർ ലോഗിൽ പ്രതികരണ കോഡും രീതിയും വായിക്കുക. ഈ ഘട്ടത്തിലെ നിരസിക്കൽ TCP കാലഹരണത്തിൽ നിന്ന് വ്യത്യസ്തമായ പ്രശ്നമാണ്, രണ്ടും വ്യത്യസ്ത പരിഹാരങ്ങളിലേക്ക് നയിക്കുന്നു.

ഘട്ടം 3: നിയന്ത്രണ സന്ദേശങ്ങൾ

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

ഇവിടെയാണ് ആഴത്തിലുള്ള പരിശോധനയുടെ മിഡിൽബോക്സ് പേരെടുക്കുന്നത്. പേജുകൾ ലോഡ് ആകുകയും VPN പരാജയപ്പെടുകയും ചെയ്യുന്നെങ്കിൽ, പോർട്ട് തുറന്നിട്ടുണ്ടോ എന്നല്ല, ബോഡി മാറ്റപ്പെടുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.

ഘട്ടം 4: PPP ഏറ്റെടുക്കുന്നു

തുടർന്ന് PPP സെഷന്റെ സ്വഭാവം നൽകുന്നു: ലിങ്ക് ചർച്ച, പ്രാമാണീകരണം, അതിന് ശേഷമുള്ള നെറ്റ്വർക്ക് പാളി കോൺഫിഗറേഷൻ. PPP പ്രാമാണീകരണം ക്ലയന്റ് ഇതിനകം കടന്ന TLS പരിശോധനയിൽ നിന്ന് വേറിട്ടതാണ്. ക്ലയന്റ് സ്വീകരിക്കുന്ന സർവർ സർട്ടിഫിക്കറ്റ് ഉപയോക്താവിന്റെ ക്രെഡൻഷ്യലുകൾ സാധുവാണോ അക്കൗണ്ട് അധികാരപ്പെടുത്തിയതാണോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

സ്വീകരിച്ച സർട്ടിഫിക്കറ്റും നിരസിച്ച ലോഗിനും പരസ്പരവിരുദ്ധമല്ല. സ്വതന്ത്ര ഫലങ്ങളുള്ള തുടർച്ചയായ ഘട്ടങ്ങളാണ് ഇവ.

പ്രാമാണീകരണത്തിന് പല പങ്കുകളുണ്ട്

ക്ലയന്റ് TLS സർവറിന്റെ അടയാളം സ്വന്തം വിശ്വാസ സംഭരണിയോടും കോൺഫിഗർ ചെയ്ത പേരിനോടും ഒത്തുനോക്കുന്നു. തുടർന്ന് PPP വിന്യാസത്തെ ആശ്രയിച്ച് ഉപയോക്താവിനെയോ യന്ത്രത്തെയോ പ്രാമാണീകരിക്കുന്നു. ആർക്ക് കണക്ട് ചെയ്യാം, എന്തിൽ എത്താം എന്നതിനെക്കുറിച്ച് സർവറിന് സ്വന്തം നയം കൂട്ടിച്ചേർക്കാം. ഹോസ്റ്റ്നാമം സർട്ടിഫിക്കറ്റ് അടയാളവുമായി പൊരുത്തപ്പെട്ട് നിർത്തുക, കാരണം അസംസ്കൃത വിലാസം ഇടുന്നത് പ്രവർത്തിക്കുന്ന ക്രമീകരണത്തെ പേര് പരിശോധനാ പരാജയമാക്കി മാറ്റുന്നു.

ഏത് ഘട്ടമാണ് പരാജയം റിപ്പോർട്ട് ചെയ്തതെന്ന് എഴുതുക. സർട്ടിഫിക്കറ്റ്, രീതി, നിയന്ത്രണ സന്ദേശം, PPP പ്രാമാണീകരണം, തുടർന്ന് റൂട്ടുകൾ: അഞ്ച് സ്ഥലങ്ങൾ, അഞ്ച് പരിഹാരങ്ങൾ.

ബ്രൗസർ പരിശോധന എന്ത് കാണിക്കാം, എന്ത് കാണിക്കാനാവില്ല

വിലാസത്തിൽ പേജ് ലോഡ് ചെയ്യുന്നത് DNS പരിഹാരം, TCP ലഭ്യത, HTTP സംസാരിക്കുന്ന എന്തോ കേൾക്കുന്നുണ്ട് എന്നിവ തെളിയിക്കുന്നു. രീതി സ്വീകരിക്കപ്പെടുന്നു, നിയന്ത്രണ കൈമാറ്റം അതിജീവിക്കുന്നു അല്ലെങ്കിൽ PPP പ്രാമാണീകരണം കോൺഫിഗർ ചെയ്തിട്ടുണ്ട് എന്ന് തെളിയിക്കുന്നില്ല. പോർട്ട് മാറ്റി മറ്റൊരു പ്രൊഫൈൽ പരിവർത്തനം ചെയ്യുന്നതിന് പകരം SSTP നടപ്പാക്കുന്ന ക്ലയന്റ് ഉപയോഗിക്കുക.

സെഷൻ ഉയർന്നതിന് ശേഷവും റൂട്ടുകൾ, DNS, സർവർ വശത്തെ ഫോർവേഡിംഗ് എന്നിവ ഉപയോക്താവിന് എന്തിൽ എത്താം എന്ന് തീരുമാനിക്കുന്നു. ടണൽ ഒരു വഴിയാണ്, അനുമതിയല്ല.