ബ്രൗസറിന്റെ HTTPS വിജയിക്കുന്നിടത്ത് SSTP പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്
SSTP പോർട്ട് 443-ൽ TLS-നുള്ളിൽ പ്രവർത്തിക്കുന്നു, പക്ഷേ അത് ഒരു വെബ് അഭ്യർത്ഥനയല്ല. TCP, TLS ഐഡന്റിറ്റി, SSTP കൈമാറ്റം, PPP പ്രാമാണീകരണം എന്നിവ വെവ്വേറെ ഘട്ടങ്ങളായി പരിശോധിക്കുക.
ബ്രൗസർ VPN ഹോസ്റ്റ്നെയിം HTTPS വഴി ഒരു പരാതിയുമില്ലാതെ തുറക്കുന്നു, എന്നാൽ SSTP ക്ലയന്റ് ഇപ്പോഴും കണക്റ്റ് ചെയ്യാൻ വിസമ്മതിക്കുന്നു. ആ ജോടിയിൽ വൈരുദ്ധ്യമില്ല. SSTP TLS-നെ പുറം ഗതാഗതമായി ഉപയോഗിച്ച്, ആ കണക്ഷനുള്ളിൽ സ്വന്തം അഭ്യർത്ഥനയും PPP പേലോഡും പ്രവർത്തിപ്പിക്കുന്നു, അതിനാൽ ഒരു പേജ് വിജയകരമായി ലോഡ് ചെയ്യുന്നത് ഒരു ചെറിയ കാര്യം മാത്രം തെളിയിക്കുന്നു: ഹോസ്റ്റ് പോർട്ട് 443-ൽ GET-ന് ഉത്തരം നൽകുന്നു. ക്ലയന്റ് മറ്റൊരു ചോദ്യം ചോദിക്കുന്നു, സെർവർ അതിന് മോശമായി ഉത്തരം നൽകിയേക്കാം.
പേജ് ലോഡ് ചെയ്യുന്നു, ടണൽ ചെയ്യുന്നില്ല
പേജ് വേഗത്തിലാണെന്നതിനാൽ ആളുകൾ ബ്രൗസർ പരിശോധനയിലേക്ക് തിരിയുന്നു, പിന്നീട് ഫലം സെർവർ എത്തിച്ചേരാവുന്നതും കോൺഫിഗർ ചെയ്തതുമാണെന്ന തെളിവായി കണക്കാക്കുന്നു. അഡ്രസ് ബാർ തുറന്ന പാതയിലേക്കുള്ള GET-നെക്കുറിച്ചുള്ള തെളിവാണത്, അതിൽ കൂടുതലല്ല. VPN സംഭാഷണം അതേ TLS ഹാൻഡ്ഷേക്കിന് ശേഷം തുടങ്ങുന്നു, പക്ഷേ അയക്കുന്നത് ഒരു വെബ് പേജ് ഒരിക്കലും ഉപയോഗിക്കാത്ത ഒരു രീതിയും പാതയും ആണ്. അതിനാൽ ബ്രൗസറിനുള്ള 200 ഉത്തരം SSTP എൻഡ്പോയിന്റ് നിലനിൽക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
രണ്ട് നിരീക്ഷണങ്ങളും വേർതിരിക്കുക, അപ്പോൾ അന്വേഷണം ചെറുതാകും. ഗതാഗതവും സർട്ടിഫിക്കറ്റ് ശൃംഖലയും പ്രവർത്തിക്കുന്നു, അവയ്ക്ക് മുകളിലുള്ള പ്രോട്ടോക്കോൾ കൈമാറ്റത്തിൽ എന്തോ പ്രവർത്തിക്കുന്നില്ല. ഇത് തകർന്ന പോർട്ടിൽ നിന്നോ കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റിൽ നിന്നോ വ്യത്യസ്തമായ അന്വേഷണമാണ്, വ്യത്യസ്ത തെളിവുകൾ ആവശ്യമാണ്.
SSTP ക്ലയന്റ് യഥാർത്ഥത്തിൽ അയക്കുന്നത്
ക്ലയന്റ് SSTP_DUPLEX_POST രീതിയിൽ /sra_{GUID}/ പാതയിലേക്ക് HTTP അഭ്യർത്ഥന അയച്ച്, പിന്നീട് കണക്ഷന്റെ ബോഡി PPP ഫ്രെയിമുകൾ വഹിക്കുന്ന ഇരുവശ ധാരയായി തുറന്ന് നിർത്തുന്നു. അനുയോജ്യമായ സെർവർ HTTP/1.1 200 എന്ന് ഉത്തരം നൽകി വെബ് സെർവർ പോലെ പെരുമാറുന്നത് നിർത്തുന്നു. മറ്റെന്തും ഒരു ഒപ്പാണ്: 405 അല്ലെങ്കിൽ 404 എന്നാൽ എൻഡ്പോയിന്റ് ഇല്ല, 301 അല്ലെങ്കിൽ 302 എന്നാൽ എന്തോ അഭ്യർത്ഥന റീഡയറക്ട് ചെയ്യുന്നു, തൽക്ഷണ FIN എന്നാൽ പ്രോക്സിയോ സെർവറോ ധാര അടച്ചു.
അതിനാൽ ലക്ഷ്യം TLS സർട്ടിഫിക്കറ്റ് ഘടിപ്പിച്ച വെബ് സെർവറല്ല, SSTP സെർവർ ആയിരിക്കണം. രീതി, പാത, ദീർഘകാല ബോഡി എന്നിവ പ്രോട്ടോക്കോൾ ആവശ്യകതകളാണ്, അതിനാൽ റിവേഴ്സ് പ്രോക്സിക്ക് കോൺഫിഗറേഷൻ കൊണ്ട് മാത്രം അവ ചേർക്കാനാവില്ല. സാധാരണ HTTPS കൃത്യമായി കൈമാറുന്ന പ്രോക്സിക്കും തനിക്ക് അറിയാത്ത രീതി നിരസിക്കാം.
പ്രോക്സിയോ വെബ് സെർവറോ ധാര എവിടെ തകർക്കുന്നു
ഇടനിലക്കാരൻ എന്തെങ്കിലും കൈമാറുന്നതിന് മുമ്പ് HTTP അഭ്യർത്ഥന വരി പരിശോധിക്കുന്നു, അസാധാരണ പാതയുള്ള ഇഷ്ടാനുസൃത രീതി അവന്റെ നിയമങ്ങളിൽ പരാജയപ്പെടാം. ചില ഉപകരണങ്ങൾ സാധാരണ പേജ് നൽകുമ്പോൾ ടണൽ നിരസിക്കുകയോ തടസ്സപ്പെടുത്തുകയോ ചെയ്യുന്നു, അതിനാൽ ക്ലയന്റ് വ്യക്തമായ നിരസിക്കലിന് പകരം തുടങ്ങി പിന്നീട് മരിക്കുന്ന കണക്ഷൻ റിപ്പോർട്ട് ചെയ്യുന്നു. മറ്റുള്ളവർ അഭ്യർത്ഥന സ്വീകരിച്ച്, പിന്നീട് PPP കീപ്പ്അലൈവുകൾക്ക് താങ്ങാനാവാത്ത ബോഡി അല്ലെങ്കിൽ നിഷ്ക്രിയ സമയപരിധി പ്രയോഗിക്കുന്നു. ക്ലയന്റ് ഭാഗത്ത് നിന്ന് രണ്ടും ഒരുപോലെ കാണപ്പെടുന്നു, അതിനാൽ ഏത് ഘട്ടം പരാജയപ്പെട്ടു എന്നത് പിശക് വാചകത്തേക്കാൾ പ്രധാനമാണ്.
ഒരു വെബ്സൈറ്റും SSTP-യും തമ്മിൽ പോർട്ട് 443 പങ്കിടുന്നത് ഒരു റൂട്ടിംഗ് തിരഞ്ഞെടുപ്പാണ്, ഓരോ ഹോപ്പും രണ്ട് സംഭാഷണങ്ങളും ഒരേ രീതിയിൽ കൈകാര്യം ചെയ്യുമെന്ന വാഗ്ദാനമല്ല. പാതയിൽ ലോഡ് ബാലൻസറോ ഫയർവാളോ TLS ടെർമിനേറ്ററോ ഉണ്ടെങ്കിൽ, VPN കോൺഫിഗറേഷൻ തൊടുന്നതിന് മുമ്പ് അത് സംശയിക്കുന്നവരുടെ പട്ടികയിൽ ചേർക്കുക.
ഘട്ടങ്ങൾ വെവ്വേറെ പരിശോധിക്കുക
പരിശോധനകൾ ക്രമത്തിൽ പ്രവർത്തിപ്പിച്ച് ആദ്യ പരാജയത്തിൽ നിൽക്കുക, ഓരോ ഘട്ടവും വ്യത്യസ്ത പാളിയെ ഒഴിവാക്കുന്നു. താഴെയുള്ള TLS പ്രോബ് സർട്ടിഫിക്കറ്റിന്റെ ഐഡന്റിറ്റിയെ SSTP ചെയ്യുന്ന എല്ലാത്തിൽ നിന്നും വേർതിരിക്കുന്നു. ഹോസ്റ്റ്നെയിം നിങ്ങളുടെ എൻഡ്പോയിന്റ് ഉപയോഗിച്ച് മാറ്റി അത് പ്രിന്റ് ചെയ്യുന്ന subject-ഉം ശൃംഖലയും വായിക്കുക.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comപിന്നീട് ക്ലയന്റ് പിശകിൽ നിന്ന് ഊഹിക്കുന്നതിന് പകരം ബാക്കിയുള്ള തെളിവുകൾ ഘട്ടങ്ങളുമായി ചേർക്കുക. താഴെയുള്ള പട്ടിക ടിക്കറ്റിൽ ഉദ്ധരിക്കാനുള്ള ചെക്ക്ലിസ്റ്റാണ്, ഒരു പരാജയത്തെ അടുത്തതിൽ നിന്ന് വേർതിരിക്കുന്ന ഒപ്പിനൊപ്പം.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
ടിക്കറ്റിൽ "കണക്റ്റ് ചെയ്യാനാവില്ല" എന്ന് എഴുതുന്നതിന് പകരം അവസാനം വിജയിച്ച ഘട്ടം രേഖപ്പെടുത്തുക. MS-SSTP സ്പെസിഫിക്കേഷൻ TLS ഹാൻഡ്ഷേക്കിന് ശേഷം വരുന്ന അഭ്യർത്ഥനയും PPP കൈമാറ്റവും രേഖപ്പെടുത്തുന്നു, ബ്രൗസർ പരിശോധന അവയിൽ ഏതിനെയും പകരം വയ്ക്കാനാവാത്തതിന്റെ അവലംബമാണത്.
ആദ്യം ഐഡന്റിറ്റി, പിന്നീട് PPP
TLS ഐഡന്റിറ്റിയും PPP പ്രാമാണീകരണവും ക്രമികമാണ്, ബദലല്ല, അവ കൂട്ടിക്കുഴയ്ക്കുന്നത് ആളുകളെ തെറ്റായ സെർവർ ക്രമീകരണത്തിലേക്ക് അയക്കുന്നു. ക്ലയന്റ് ആദ്യം സെർവർ സർട്ടിഫിക്കറ്റും അതിന്റെ ഉദ്ദേശിച്ച ഉപയോഗവും സാധൂകരിക്കുന്നു, പിന്നീട് PPP സ്വന്തം അവസ്ഥ ചർച്ച ചെയ്ത് ഉപയോക്താവിനെ ചലഞ്ച്-റെസ്പോൺസ് രീതി അല്ലെങ്കിൽ EAP ഉപയോഗിച്ച് പ്രാമാണീകരിക്കുന്നു. സർട്ടിഫിക്കറ്റ് പ്രശ്നം നിരസിക്കപ്പെട്ട പാസ്വേഡിൽ നിന്ന് വ്യത്യസ്തമായ പിശക് നൽകുന്നു, ഒരു പിശകും മറ്റൊന്ന് ഉൾക്കൊള്ളുന്ന ഘട്ടം വിവരിക്കുന്നില്ല.
ഹോസ്റ്റ്നെയിം വിലാസം കൊണ്ട് മാറ്റുന്നതോ സർട്ടിഫിക്കറ്റ് മുന്നറിയിപ്പ് അവഗണിച്ച് ക്ലിക്ക് ചെയ്യുന്നതോ പരാജയപ്പെടുന്ന ഘട്ടം തിരിച്ചറിയുമായിരുന്ന പരിശോധന നന്നാക്കുന്നതിന് പകരം നീക്കം ചെയ്യുന്നു. മുന്നറിയിപ്പ് സൂക്ഷിച്ച് വായിക്കുക. HTTP കൈമാറ്റം ഒരിക്കലും SSTP പെരുമാറ്റത്തിൽ എത്തിയിട്ടില്ലെങ്കിൽ PPP പാസ്വേഡ് പുനഃസജ്ജമാക്കരുത്, കാരണം ക്രെഡൻഷ്യലുകൾ ഒരിക്കലും ആവശ്യപ്പെട്ടിട്ടില്ല.