HTTPS വഴിയുള്ള അടിസ്ഥാന പ്രാമാണീകരണവും IPsec-ഉം: ഓരോന്നും എന്താണ് സംരക്ഷിക്കുന്നത്

ഡെവലപ്പർ ടൂളുകൾ തുറന്ന്, ആന്തരിക ആപ്പ് ലോഡ് ചെയ്ത്, പേജ് റെൻഡർ ചെയ്യുന്നതിന് മുമ്പ് ഒരു അഭ്യർത്ഥന നാല് പരിശോധനാ പോയിന്റുകളിലൂടെ കടന്നുപോകുന്നത് നിരീക്ഷിക്കുക। ആദ്യം പേര് പരിഹരിക്കപ്പെടുന്നു, തുടർന്ന് ഒരു TCP കണക്ഷൻ തുറക്കുന്നു, തുടർന്ന് TLS ഹാൻഡ്ഷേക്ക് സെർവർ ആരെന്ന് സ്ഥാപിക്കുന്നു, അതിനുശേഷം മാത്രം നിങ്ങൾ ആരെന്ന് ആപ്ലിക്കേഷൻ ചോദിക്കുന്നു। ഇവയെ വേറിട്ട സംഭവങ്ങളായി കാണുക, കാരണം ഓരോന്നും വ്യത്യസ്ത തെളിവുകളോടെ പരാജയപ്പെടുന്നു, ഓരോന്നിനും വ്യത്യസ്ത ടീമാണ് ഉത്തരവാദി। സംഭവങ്ങളിലെ മിക്ക ആശയക്കുഴപ്പവും 401-നെ ടണൽ പ്രശ്നമായി വായിക്കുന്നതിൽ നിന്നോ, ടണൽ പ്രശ്നത്തെ തെറ്റായ പാസ്വേഡായി വായിക്കുന്നതിൽ നിന്നോ വരുന്നു।

പരിശോധനാ പോയിന്റ് ഒന്ന്: നിങ്ങൾ സംസാരിക്കാൻ ഉദ്ദേശിച്ച സെർവർ ഇതാണോ

ഏതെങ്കിലും ക്രെഡൻഷ്യൽ അയയ്ക്കുന്നതിന് മുമ്പ് TLS ഹാൻഡ്ഷേക്ക് ആ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു। നിങ്ങളുടെ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ശൃംഖല ട്രസ്റ്റ് സ്റ്റോറിനെതിരെ സാധൂകരിക്കുകയും സർട്ടിഫിക്കറ്റിലെ പേര് നിങ്ങൾ ടൈപ്പ് ചെയ്ത ഹോസ്റ്റുമായി പൊരുത്തപ്പെടുന്നുവെന്ന് പരിശോധിക്കുകയും ചെയ്യുന്നു। അത് പരാജയപ്പെട്ടാൽ, ബ്രൗസർ സർട്ടിഫിക്കറ്റ് പിശക് കാണിക്കുന്നു, Authorization ഹെഡർ അസ്സലായി അയയ്ക്കുന്നുമില്ല। അതിനാൽ പാസ്വേഡ് അഭ്യർത്ഥന സെർവർ യഥാർത്ഥമാണെന്ന തെളിവല്ല; ആപ്ലിക്കേഷൻ ഉത്തരം നൽകി എന്നതിന്റെ തെളിവാണ്।

ഇവിടെ ആദ്യ അതിർത്തി പ്രത്യക്ഷപ്പെടുന്നു। TLS അതിന്റെ അവസാന പോയിന്റ് വരെ കണക്ഷനെ സംരക്ഷിക്കുന്നു। ലോഡ് ബാലൻസർ TLS അവസാനിപ്പിച്ച് ലളിതമായ HTTP ആപ്ലിക്കേഷനിലേക്ക് കൈമാറുന്നുവെങ്കിൽ, എൻക്രിപ്റ്റ് ചെയ്ത ഭാഗം ബാലൻസറിൽ അവസാനിക്കുന്നു, ക്രെഡൻഷ്യലുകൾ ആ ആദ്യ ചുവടിൽ മാത്രം സംരക്ഷിക്കപ്പെടുന്നു।

പരിശോധനാ പോയിന്റ് രണ്ട്: 401 കൈമാറ്റത്തിൽ യഥാർത്ഥത്തിൽ എന്താണ് സഞ്ചരിക്കുന്നത്

HTTP അടിസ്ഥാന പ്രാമാണീകരണം ഉപയോക്തൃ ഐഡന്റിഫയറും പാസ്വേഡും ഒരു ഹെഡറിൽ അയയ്ക്കുന്നു, Base64 ഉപയോഗിച്ച് എൻകോഡ് ചെയ്ത്, വിവരിച്ചിരിക്കുന്നതുപോലെ RFC 7617 എന്നതിൽ. Authorization: Basic dXNlcjpwYXNz അതിന്റെ രൂപമാണ്; അഭ്യർത്ഥന വായിക്കാൻ കഴിയുന്ന ആർക്കും എൻകോഡിംഗ് പഴയപടിയാക്കാം, അതിനാൽ എല്ലാ രഹസ്യാത്മകതയും താഴെയുള്ള ഗതാഗതത്തിൽ നിന്ന് വരുന്നു. curl -v WWW-Authenticate: Basic വെല്ലുവിളിയും നിങ്ങൾ തിരികെ അയയ്ക്കുന്ന ഹെഡറും കാണിക്കുന്നു।

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

ആ പാതയിൽ IPsec ടണൽ എവിടെയാണ്

ഇപ്പോൾ ബ്രൗസറിൽ നിന്ന് പുറത്തേക്ക് നടക്കുക। ഗേറ്റ്വേ-തോ-ഗേറ്റ്വേ IPsec ടണൽ രണ്ട് സുരക്ഷാ ഗേറ്റ്വേകൾക്കിടയിലുള്ള തിരഞ്ഞെടുത്ത ട്രാഫിക്കിനെ സംരക്ഷിക്കുന്നു, നിങ്ങളുടെ ലാപ്ടോപ്പും ആപ്ലിക്കേഷൻ പ്രോസസ്സും തമ്മിലല്ല। ടണൽ മോഡ് ESP യഥാർത്ഥ പാക്കറ്റ് പൊതിയുന്നു, ഗേറ്റ്വേകൾ അത് എൻക്രിപ്റ്റ് ചെയ്ത് പ്രാമാണീകരിക്കുന്നു, ആന്തരിക വിലാസങ്ങൾ നിലനിൽക്കുന്നു അതിനാൽ ദൂരെയുള്ള വശത്തിന് അഭ്യർത്ഥന ആപ്ലിക്കേഷനിലേക്ക് റൂട്ട് ചെയ്യാം।

തിരഞ്ഞെടുപ്പാണ് ആളുകൾ ഇടറുന്ന ഭാഗം। നയാധിഷ്ഠിത ടണലുകൾ ട്രാഫിക് സെലക്ടറുകൾ ഉപയോഗിക്കുന്നു, പലപ്പോഴും ആക്സസ് കൺട്രോൾ ലിസ്റ്റുകളായി പ്രകടിപ്പിക്കുന്നു, ഏത് പാക്കറ്റുകൾ ടണലിൽ പ്രവേശിക്കുന്നുവെന്ന് തീരുമാനിക്കാൻ। റൂട്ട് അധിഷ്ഠിത ടണലുകൾ പകരം ഒരു വെർച്വൽ ഇന്റർഫേസും റൂട്ടിംഗ് ടേബിളും ഉപയോഗിക്കുന്നു। Linux-ൽ ip xfrm policy സെലക്ടറുകൾ കാണിക്കുന്നു, ip xfrm state സ്ഥാപിത സുരക്ഷാ അസോസിയേഷനുകൾ കാണിക്കുന്നു; ഫയർവാൾ ഉപകരണത്തിൽ തത്തുല്യമായത് ടണലിന്റെ SA ടേബിളും ഒരു പാക്കറ്റ് ട്രെയ്സറുമാണ്।

ഫലം വ്യക്തമായി പറയാൻ യോഗ്യമാണ്। ഒരു പാക്കറ്റിന് പൂർണ്ണമായും ആരോഗ്യകരമായ ടണലിനുള്ളിൽ ഇരിക്കാം, എന്നിട്ടും ആപ്ലിക്കേഷൻ നിരസിക്കുന്ന ഒരു HTTPS അഭ്യർത്ഥന വഹിക്കാം, കൂടാതെ സാധുവായ ക്രെഡൻഷ്യലുകൾ ടണലില്ലാത്ത ഒരു പാതയിലൂടെയും എത്താം, റൂട്ടിംഗ് അനുവദിക്കുകയാണെങ്കിൽ।

പരാജയം റിപ്പോർട്ട് ചെയ്ത പാളിയിൽ വായിക്കുക

401 എന്നാൽ ആപ്ലിക്കേഷൻ ക്രെഡൻഷ്യൽ സ്വീകരിച്ചില്ല എന്നാണ്। 403 എന്നാൽ അത് ഐഡന്റിറ്റി സ്വീകരിച്ച് പ്രവർത്തനം നിരസിച്ചു എന്നാണ്। TLS പിശക് എന്നാൽ ക്ലയന്റ് സെർവർ സ്വീകരിച്ചില്ല എന്നാണ്। റൂട്ട് ഇല്ലാത്തതോ നയ പൊരുത്തക്കേടോ എന്നാൽ പാക്കറ്റ് ഒരിക്കലും ദൂരെയുള്ള ഗേറ്റ്വേയിൽ എത്തിയില്ല എന്നാണ്। നാല് വ്യത്യസ്ത പരാജയങ്ങൾ, നാല് വ്യത്യസ്ത ഉടമകൾ, ലോഗിൻ ഫോമിലേക്ക് നോക്കിയിട്ട് ഇവയൊന്നും രോഗനിർണ്ണയം ചെയ്യാൻ കഴിയില്ല।

ഓരോ പാളിയും ഉൽപ്പാദിപ്പിക്കുന്ന തെളിവുകൾ ഉപയോഗിക്കുക: സ്റ്റാറ്റസും ഹെഡറുകളും ബ്രൗസറിന്റെ നെറ്റ്വർക്ക് പാനലിൽ, സർട്ടിഫിക്കറ്റ് ശൃംഖലയ്ക്ക് openssl s_client -connect host:443, ടണൽ ട്രാഫിക്കിന് ഗേറ്റ്വേയുടെ SA കൗണ്ടറുകളും ലോഗുകളും, അക്കൗണ്ട് തീരുമാനത്തിന് ആപ്ലിക്കേഷൻ ലോഗും। രണ്ട് പാളികൾ ഒരേസമയം പിശകുകൾ റിപ്പോർട്ട് ചെയ്യുമ്പോൾ, ആദ്യം താഴത്തെത് ശരിയാക്കുക, കാരണം മരിച്ച ടണലിന് പ്രാമാണീകരണ പരാജയം എളുപ്പത്തിൽ മറയ്ക്കാം, തിരിച്ചും।

ഒരു സേവനം തുടക്കം മുതൽ അവസാനം വരെ മാപ്പ് ചെയ്യുക

നിങ്ങൾ പരിശോധിക്കുന്ന സേവനത്തിനായി അഞ്ച് വരികൾ എഴുതുക: ടണൽ ഏത് സമപ്രായക്കാരെ ബന്ധിപ്പിക്കുന്നു, സെലക്ടറുകൾ ഏത് സബ്നെറ്റുകൾക്കും പോർട്ടുകൾക്കും അനുമതി നൽകുന്നു, TLS എവിടെ അവസാനിക്കുന്നു, സർട്ടിഫിക്കറ്റ് ഏത് ഐഡന്റിറ്റി ഉറപ്പിക്കുന്നു, ഏത് ആപ്ലിക്കേഷൻ അക്കൗണ്ടും റോളും ഉപയോഗിക്കുന്നു, ഓരോ പാളിയും എവിടെ ലോഗ് ചെയ്യുന്നു। അവ ഒരു പേജിൽ സൂക്ഷിക്കുക, കാരണം മാപ്പിന്റെ ഉദ്ദേശ്യം ഒരു പാളിയുടെ ഉത്തരവാദിത്വം എവിടെ അവസാനിക്കുന്നു, അടുത്തത് എവിടെ തുടങ്ങുന്നു എന്ന് കാണിക്കുകയാണ്।

തുടർന്ന് ഓരോ പാളിക്കും ഒരു നെഗറ്റീവ് കേസ് പരീക്ഷിക്കുക। തെറ്റായ പാസ്വേഡ് ഉപയോഗിച്ച് ടൈംഔട്ടല്ല, 401 ലഭിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക। സെലക്ടറുകൾക്ക് പുറത്തുള്ള ഒരു സബ്നെറ്റിൽ നിന്ന് കണക്ട് ചെയ്ത് പാക്കറ്റ് ടണലിലൂടെ പോകുന്നില്ലെന്ന് ഉറപ്പാക്കുക। തെറ്റായ പേരിന് സർട്ടിഫിക്കറ്റ് അവതരിപ്പിച്ച് ക്രെഡൻഷ്യലുകൾ അയയ്ക്കുന്നതിന് മുമ്പ് ക്ലയന്റ് നിരസിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക। ആ മൂന്ന് ഫലങ്ങൾ ഡിസൈനിനെക്കുറിച്ച് ഏതൊരു ബോക്സ് ഡയഗ്രത്തെക്കാളും കൂടുതൽ പറയുന്നു।

അവസാനമായി, ഓരോ ബന്ധത്തിനും ഏത് സംരക്ഷണം വേണമെന്ന് ബോധപൂർവ്വം തീരുമാനിക്കുക। TLS-ന് മുകളിലുള്ള അടിസ്ഥാന പ്രാമാണീകരണം ഗേറ്റ്വേയ്ക്ക് പിന്നിലുള്ള ചെറിയ ആന്തരിക ഉപകരണത്തിന് ന്യായമായ തിരഞ്ഞെടുപ്പാണ്; അത് ഓരോ ഉപയോക്താവിനുമുള്ള അംഗീകരണത്തിനോ TLS അവസാന പോയിന്റിന് അപ്പുറമുള്ള ട്രാഫിക് സംരക്ഷണത്തിനോ പകരമല്ല। ടണൽ പാതയെ സംരക്ഷിക്കുന്നു, സർട്ടിഫിക്കറ്റ് ചുവടിനെ സംരക്ഷിക്കുന്നു, 401 അക്കൗണ്ടിനെ സംരക്ഷിക്കുന്നു, നിങ്ങൾ ആരെന്ന് അറിയുന്നത് അവസാനത്തേതിന് മാത്രം।