SSTP പാളികൾ വിശദീകരണം: ഉള്ളിലെ പാക്കറ്റ് ഇപ്പോഴും എന്തു വെളിപ്പെടുത്തുന്നു

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

പുറത്തെ വാഹകനിൽ തുടങ്ങുക

കമ്പിയിൽ ആദ്യം വരുന്നത് പോർട്ട് 443-ലേക്കുള്ള സാധാരണ TCP ബന്ധമാണ്, റൗട്ടറുകൾ കൈമാറുന്ന യഥാർത്ഥ വിലാസങ്ങളോടെ. ആ ബന്ധമാണ് നെറ്റ്വർക്ക് വിലാസ പരിഭാഷയെ അതിജീവിക്കുന്നതും ആക്സസ് ദാതാവിന് എണ്ണാൻ കഴിയുന്നതും. പേലോഡ് സംരക്ഷിക്കുന്നത് വാഹകനെ നീക്കില്ല, കൂടാതെ അത് അളവോ സമയമോ മറയ്ക്കുന്നുമില്ല.

ഈ ബിന്ദുവിനു ശേഷമുള്ളതെല്ലാം റൂട്ട് ചെയ്യുന്നതിനു പകരം വഹിക്കപ്പെടുന്നു. ഉള്ളിലെ കൈമാറ്റം പരാജയപ്പെട്ടാലും വാഹകൻ പ്രവർത്തിക്കുന്നു.

എൻകാപ്സുലേഷൻ അകത്തേക്ക് പിന്തുടരുക

സംരക്ഷിത ചാനലിനുള്ളിൽ ഒരു SSTP നിയന്ത്രണ കൈമാറ്റം ഇരിക്കുന്നു, പിന്നെ ഒരു PPP സെഷൻ, പിന്നെ ക്ലയന്റ് എത്തിക്കാൻ ആഗ്രഹിക്കുന്ന നെറ്റ്വർക്ക് പാക്കറ്റ്. ഓരോ പാളിക്കും അതിന്റേതായ ചർച്ചകൾ, സ്വന്തം പിശക് സന്ദേശങ്ങൾ, സ്വന്തം അവസ്ഥ യന്ത്രം എന്നിവയുണ്ട്. അതിനാൽ ഒരു തകരാർ ഒരു കാഴ്ചയിൽ TLS തകരാറായും മറ്റൊന്നിൽ PPP തകരാറായും തോന്നാം. പാളികൾ ക്രമത്തിൽ വായിച്ചാൽ ഏത് അവസ്ഥ യന്ത്രം നിന്നു എന്നു മനസ്സിലാകും.

ഒരു ക്യാപ്ചർ മുഴുവൻ സ്റ്റാക്കും അപൂർവമായി മാത്രമേ കാണിക്കൂ. പുറത്തെ തലക്കെട്ടുകൾ അന്തിമ ബിന്ദുവിനു പുറത്തു മാത്രം കാണാം, ഉള്ളിലെവ ഡീകാപ്സുലേഷനു ശേഷം മാത്രം. ഈ അസമത്വം നിങ്ങൾ നിൽക്കുന്ന സ്ഥലത്തുനിന്നാണ് വരുന്നത്, പ്രോട്ടോക്കോളിൽനിന്നല്ല.

താഴെയുള്ള ചിത്രം പാളികളെ കൂട്ടിച്ചേർക്കുന്നു, അവയെപ്പറ്റി സംസാരിക്കാൻ എങ്കിലും കഴിയാൻ. ഇത് ബൈറ്റ് ക്രമമല്ല, ഓരോ പാക്കറ്റിനും ഒരു രേഖ വാഗ്ദാനം ചെയ്യുന്നില്ല, ഒരു നടപ്പാക്കൽ എത്ര ക്രിപ്റ്റോഗ്രാഫിക് പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു എന്നതിനെപ്പറ്റി ഒന്നും പറയുന്നുമില്ല.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

ക്യാപ്ചർ വായിക്കുന്നതിനു മുൻപ് നിരീക്ഷകനെ അടയാളപ്പെടുത്തുക

ഒരേ സെഷന്റെ രണ്ടു ക്യാപ്ചറുകൾ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, ഏതിന് ഏത് എന്നത് അവ എടുത്ത ഇന്റർഫേസ് തീരുമാനിക്കുന്നു. ആക്സസ് പാതയിൽ നിങ്ങൾ വാഹകനെയും TLS രേഖകളെയും കാണുന്നു, ഉള്ളിലെ വിലാസം കാണാതെ വലിപ്പവും ഇടവേളയും അളക്കാം. അന്തിമ ബിന്ദുവിൽ, ഡീകാപ്സുലേഷനു ശേഷം, ഉള്ളിലെ പാക്കറ്റ് സ്വകാര്യ ഫോർവേഡിംഗ് നയത്തിൻ കീഴിലുള്ള സാധാരണ ട്രാഫിക്കാണ്.

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

ചിത്രത്തിന് തെളിയിക്കാനാവാത്ത പരിശോധനകൾ നിലനിർത്തുക

പാളികളുടെ ക്രമം ഒരു വിന്യാസം സർവർ സർട്ടിഫിക്കറ്റ് സാധൂകരിക്കുന്നു, പിന്തുണയുള്ള TLS പതിപ്പിൽ ചർച്ച ചെയ്യുന്നു, അല്ലെങ്കിൽ അക്കൗണ്ടിന് അധികാരം നൽകുന്നു എന്നു തെളിയിക്കുന്നില്ല. അവയോരോന്നും എൻകാപ്സുലേഷനിൽനിന്ന് സ്വതന്ത്രമായി പരാജയപ്പെടുന്ന ക്രമീകരണ തീരുമാനമാണ്.

ചിത്രത്തിൽനിന്ന് അനുമാനിക്കുന്നതിനു പകരം എന്തിൽ ചർച്ച ചെയ്തു എന്നു റിപ്പോർട്ട് ചെയ്യുന്ന ക്ലയന്റിനൊപ്പം അവ പരിശോധിക്കുക. TLS ഹാൻഡ്ഷേക്കിൽ തുടങ്ങി, പിന്നെ SSTP കൈമാറ്റം, പിന്നെ PPP, പിശക് റിപ്പോർട്ട് ചെയ്യുന്ന ആദ്യ ഘട്ടത്തിൽ നിർത്തുക. ആദ്യ കമാൻഡ് ശൃംഖലയും ചർച്ച ചെയ്ത പതിപ്പും അച്ചടിക്കുന്നു, രണ്ടാമത്തേത് ക്യാപ്ചറിലുള്ള ഹാൻഡ്ഷേക്കുകൾ പട്ടികപ്പെടുത്തുന്നു.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"