TLS പരിശോധിക്കുന്ന പ്രോക്സിക്ക് പിന്നിലെ SSTP: സെഷൻ എവിടെ മുറിയുന്നു

നിങ്ങളുടെ ബ്രൗസർ കോർപ്പറേറ്റ് ഇന്ട്രാനെറ്റ് ലോഡ് ചെയ്യുന്നു, പ്രോക്സി സർട്ടിഫിക്കറ്റ് വിശ്വസനീയമാണ്, എന്നിട്ടും SSTP ക്ലയന്റ് കണക്ഷന്റെ അവസാനത്തോട് അടുത്ത് വീഴുന്നു. ഈ മാതൃക തെറ്റായ പാസ്വേഡിനെയല്ല, വെബ് അഭ്യർത്ഥനയും ടണൽ സെഷനും തമ്മിലുള്ള വ്യത്യാസത്തെയാണ് സൂചിപ്പിക്കുന്നത്. TCP മുതൽ മുകളിലോട്ട് കണക്ഷനിലൂടെ കടന്ന് ആദ്യം പരാജയപ്പെടുന്ന ഘട്ടം രേഖപ്പെടുത്തുക. പ്രോക്സിയാണോ കാരണം എന്ന് പിശക് കോഡല്ല, ഘട്ടമാണ് പറയുന്നത്.

ക്ലയന്റ് നിൽക്കുന്നിടത്ത് നിന്ന് തുടങ്ങുക

ക്ലയന്റ് ഒരു നിശ്ചിത ക്രമത്തിലൂടെ കടക്കുന്നു: പോർട്ട് 443-ലേക്കുള്ള TCP കണക്ഷൻ, TLS ഹാൻഡ്ഷേക്ക്, സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരണം, SSTP-യുടെ HTTP കൈമാറ്റം, PPP ചർച്ചയും പ്രാമാണീകരണവും, തുടർന്ന് IP കോൺഫിഗറേഷൻ. ഓരോ ഘട്ടത്തിലെയും പരാജയം വ്യത്യസ്ത അടയാളം വിടുന്നു, അവ കൂട്ടിക്കലർത്തുന്നത് തെറ്റായ കോൺഫിഗറേഷൻ പേജിലെത്തിക്കുന്നു.

TCP പരാജയം എന്നത് ഏതെങ്കിലും TLS ബൈറ്റ് പ്രത്യക്ഷപ്പെടുന്നതിന് മുമ്പുള്ള ടൈംഔട്ട് അല്ലെങ്കിൽ റീസെറ്റ് ആണ്. TLS പരാജയം മുന്നറിയിപ്പോ ഹാൻഡ്ഷേക്ക് ടൈംഔട്ടോ ആണ്. സർട്ടിഫിക്കറ്റ് പരാജയം ശൃംഖലയെയോ പേരിനെയോ കുറിച്ച് മുന്നറിയിപ്പ് നൽകുന്നു. HTTP പരാജയം വിജയകരമായ ഹാൻഡ്ഷേക്കിന് ശേഷം വരുന്നു, പലപ്പോഴും സ്റ്റാറ്റസ് കോഡായോ ഉടൻ അടയ്ക്കലായോ. PPP പരാജയം ടണൽ സാങ്കേതികമായി സ്ഥാപിച്ചതിന് ശേഷം വരുന്നു, അതുകൊണ്ടാണ് അത് പ്രാമാണീകരണ പ്രശ്നമായി തോന്നുന്നത്.

ആദ്യ പിശക് വരിയല്ല, ക്ലയന്റ് ലോഗിലെ അവസാന വിജയകരമായ ഘട്ടം വായിക്കുക. പിശക് വരി സാധാരണയായി ഫലം അറിയിക്കുന്നു, അതേസമയം ഘട്ടത്തിന്റെ അതിർത്തി നിരസിച്ച ഘടകത്തെ പേരിടുന്നു.

SSTP നെറ്റ്വർക്കിൽ നിന്ന് എന്ത് വഹിക്കാനാണ് ആവശ്യപ്പെടുന്നത്

SSTP TCP 443-ൽ TLS-ന് മുകളിലൂടെ പ്രവർത്തിക്കുന്നു, തുടർന്ന് SSTP വിവരണത്തിൽ നിർവചിച്ചിരിക്കുന്ന SSTP_DUPLEX_POST എന്ന HTTP അഭ്യർത്ഥന /sra_{GUID}/ എന്ന രൂപത്തിലുള്ള പാതയിലേക്ക് അയയ്ക്കുന്നു. അഭ്യർത്ഥന പ്രായോഗികമായി അപരിമിതമായ ഉള്ളടക്ക നീളം പ്രഖ്യാപിക്കുകയും സെഷന്റെ മുഴുവൻ കാലത്തും സ്ട്രീം ഇരു ദിശകളിലും തുറന്ന് നിർത്തുകയും ചെയ്യുന്നു. PPP ഫ്രെയിമുകൾ ആ സ്ട്രീമിനുള്ളിൽ സഞ്ചരിക്കുന്നു.

അതുകൊണ്ടാണ് സാധാരണ ബ്രൗസിംഗ് കൈകാര്യം ചെയ്യുന്ന പ്രോക്സിക്കും പരാജയപ്പെടാനാകുന്നത്. പരിമിതമായ ബോഡിയുള്ള GET അല്ലെങ്കിൽ POST ബഫർ ചെയ്ത് പരിശോധിച്ച് കൈമാറാനാകും; ഒരിക്കലും അവസാനിക്കാത്ത ബോഡിയുള്ള ഡ്യുപ്ലെക്സ് സ്ട്രീം സാധ്യമല്ല. ബോഡി പൂർത്തിയാകാൻ കാത്തിരിക്കുന്ന പ്രോക്സി എന്നും കാത്തിരിക്കും, ക്ലയന്റ് ഒടുവിൽ ടൈംഔട്ട് ആകും.

രീതി ഫിൽട്ടറിംഗും പ്രാമാണീകരണവും സ്വന്തം പരാജയ മാതൃകകൾ കൂട്ടിച്ചേർക്കുന്നു. പ്രോക്സി അഭ്യർത്ഥനയ്ക്ക് രേഖകൾ ആവശ്യപ്പെട്ടാൽ ബ്രൗസർ ഉത്തരം നൽകുമെങ്കിലും VPN ക്ലയന്റ് നൽകണമെന്നില്ല. അത് രീതി നീക്കുകയോ വീണ്ടും എഴുതുകയോ ചെയ്താൽ PPP തുടങ്ങുന്നതിന് മുമ്പ് ഗേറ്റ്വേ അഭ്യർത്ഥന തള്ളിക്കളയുന്നു.

പരിശോധന ഐഡന്റിറ്റി എന്തുകൊണ്ട് മാറ്റുന്നു

TLS പരിശോധിക്കുന്ന പ്രോക്സി ക്ലയന്റിന്റെ TLS കണക്ഷൻ അവസാനിപ്പിച്ച് ഗേറ്റ്വേയിലേക്ക് വേറെ കണക്ഷൻ തുറക്കുന്നു. അതിനാൽ ക്ലയന്റ് ഗേറ്റ്വേയുടെയല്ല, പ്രോക്സിയുടെ സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരിക്കുന്നു, ഗേറ്റ്വേ പ്രോക്സിയെ തന്റെ പങ്കാളിയായി കാണുന്നു. സ്ഥാപനം സ്വന്തം റൂട്ട് വിതരണം ചെയ്യുമ്പോൾ ബ്രൗസറിനും VPN ക്ലയന്റിനും ആ ശൃംഖല സ്വീകരിക്കാനാകും, അതിനാൽ ഹാൻഡ്ഷേക്ക് വിജയിക്കുകയും പ്രശ്നം അടുത്ത ഘട്ടത്തിലേക്ക് പോകുകയും ചെയ്യുന്നു.

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

അതുകൊണ്ടാണ് അപരിചിതമായ റൂട്ട് ചേർക്കുന്നതോ സ്ഥിരീകരണം ഓഫ് ചെയ്യുന്നതോ തെറ്റായ അറ്റകുറ്റപ്പണിയാകുന്നത്. ക്ലയന്റ് ഏത് സർട്ടിഫിക്കറ്റ് സ്വീകരിക്കുന്നു എന്ന് അത് മാറ്റുന്നു; സെഷൻ യഥാർത്ഥത്തിൽ തകർത്ത സ്ട്രീം കൈകാര്യം ചെയ്യലിനെക്കുറിച്ച് അത് ഒന്നും ചെയ്യുന്നില്ല.

ക്രമീകരണങ്ങൾ മാറ്റുന്നതിന് മുമ്പ് ഇഷ്യൂ ചെയ്യുന്നയാളെ തിരിച്ചറിയുക

ഏത് സർട്ടിഫിക്കറ്റാണ് അവതരിപ്പിക്കുന്നതെന്നും ആരാണ് അതിൽ ഒപ്പിട്ടതെന്നും എൻഡ്പോയിന്റിനോട് ചോദിക്കുക. ചുവടെയുള്ള കമാൻഡുകൾ VPN സെഷൻ തുടങ്ങാതെ ശൃംഖലയും ഇഷ്യൂ ചെയ്യുന്നയാളെയും കാണിക്കുന്നു:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

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

അതേ ഹോസ്റ്റിലേക്കുള്ള ബ്രൗസർ പരിശോധന പ്രോക്സി GET സ്വീകരിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു. SSTP രീതി, അഭ്യർത്ഥന URI, ബോഡിയുടെ ആയുസ്സ് എന്നിവയെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല, അതിനാൽ പ്രവർത്തിക്കുന്ന ഇന്ട്രാനെറ്റ് പേജിനെ ടണൽ പാതയ്ക്ക് പിന്തുണയുണ്ടെന്ന തെളിവായി കാണരുത്.

പിന്തുണയുള്ള പാത തിരഞ്ഞെടുക്കുക

നെറ്റ്വർക്ക് ഉടമയോട് ഒരു കൃത്യമായ ചോദ്യം ചോദിക്കുക: ഈ ഗേറ്റ്വേയിലേക്ക് പോർട്ട് 443-ൽ ബഫർ ഇല്ലാത്ത ഡ്യുപ്ലെക്സ് POST അനുവദിക്കുന്നുണ്ടോ? അതെ എന്നാൽ പ്രോക്സിയിൽ ഒരു ഒഴിവ് അല്ലെങ്കിൽ VPN ഹോസ്റ്റിനായി രേഖപ്പെടുത്തിയ ഒഴിവാക്കൽ. ഇല്ല എന്നാൽ പരിശോധിച്ച പാതയ്ക്ക് SSTP വഹിക്കാനാകില്ല, പിന്തുണയുള്ള പരിഹാരം ക്ലയന്റ് ക്രമീകരണമല്ല, മറ്റൊരു പാതയോ പ്രോട്ടോക്കോളോ ആണ്.

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

ഫലം രേഖപ്പെടുത്തുക: ഇഷ്യൂ ചെയ്യുന്നയാൾ, പരാജയപ്പെട്ട ഘട്ടം, പ്രോക്സി നിയമം, തിരഞ്ഞെടുത്ത പാത. അടുത്ത വ്യക്തിക്ക് അതേ 98 ശതമാനം തടസ്സം കാണുമ്പോൾ മുഴുവൻ സഞ്ചാരവും ആവർത്തിക്കുന്നതിന് പകരം ഒരു വസ്തുത പരിശോധിക്കാനാകും.