TLS VPN vs IPsec: പരിശോധിക്കേണ്ട അഞ്ച് മേഖലകൾ
TLS VPN, IPsec VPN എന്നിവയെ റിലീസ്, പ്രോട്ടോക്കോൾ പതിപ്പ്, സ്യൂട്ട്, സഹയാത്രിക തിരിച്ചറിയൽ, വെളിപ്പെടുത്തിയ പരിധി എന്നിവയുടെ അടിസ്ഥാനത്തിൽ താരതമ്യം ചെയ്യുക, കൂടാതെ നിങ്ങൾ യഥാർത്ഥത്തിൽ കോൺഫിഗർ ചെയ്ത പരാജയ-ഫലത്തിന്റെ അടിസ്ഥാനത്തിലും.
TLS VPN-കളെ IPsec VPN-കളുമായി പ്രോട്ടോക്കോൾ കുടുംബത്തിന്റെ അടിസ്ഥാനത്തിൽ ക്രമീകരിക്കുന്നത് ആരും ചോദിക്കാത്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, കൂടാതെ രണ്ട് കുടുംബങ്ങളും വർഷങ്ങൾക്ക് മുമ്പ് ഉപേക്ഷിച്ച ഒരു നിർമ്മാണം സാധാരണയായി ഉദ്ധരിക്കുന്നു. ഒരു അവലോകകന് യഥാർത്ഥത്തിൽ വിലയിരുത്താൻ കഴിയുന്നത് ചർച്ച ചെയ്ത സംരക്ഷണം, സഹയാത്രിക തിരിച്ചറിയൽ, ക്ലയന്റ് മാതൃക, വെളിപ്പെടുത്തിയ സേവനം എന്നിവയാണ്. ഈ നാലും വിന്യാസത്തിൽ കാണാം, ഒന്നും ഉൽപ്പന്ന ലേബലിൽ നിന്ന് വരുന്നില്ല. അഞ്ച് മേഖലകൾ ചോദിക്കുക, സംഭാഷണം കൃത്യമാകും.
അഞ്ച് മേഖലകൾ, ലേബൽ അവയിൽ ഒന്നല്ല
ആദ്യ മേഖല പിന്തുണയുള്ള സോഫ്റ്റ്വെയർ റിലീസ്, കാരണം പതിപ്പില്ലാത്ത പ്രോട്ടോക്കോൾ വിവരണം ഒരു പരസ്യപത്രമാണ്. രണ്ടാമത്തേത് ചർച്ച ചെയ്ത പ്രോട്ടോക്കോൾ പതിപ്പ്, ഏത് നിർമ്മാണങ്ങൾ ലഭ്യമാണെന്ന് അത് തീരുമാനിക്കുന്നു. മൂന്നാമത്തേത് സംരക്ഷണ സ്യൂട്ട്, നാലാമത്തേത് സഹയാത്രികനും ഉപയോക്താവിനും ഉള്ള പ്രാമാണീകരണ രീതി, അഞ്ചാമത്തേത് പ്രവേശനത്തിന് ശേഷം ഉൽപ്പന്നം നൽകുന്ന ആക്സസ് പരിധി.
SSL VPN ലേബൽ കുറഞ്ഞത് മൂന്ന് വ്യത്യസ്ത ഉൽപ്പന്നങ്ങൾ ഉൾക്കൊള്ളുന്നു: പൂർണ്ണ നെറ്റ്വർക്ക് ക്ലയന്റ്, ആപ്ലിക്കേഷൻ പ്രോക്സി, ബ്രൗസർ അടിസ്ഥാനമാക്കിയ പഴയ പോർട്ടൽ. അവ വ്യത്യസ്ത സേവനങ്ങൾ വെളിപ്പെടുത്തി വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു, അതിനാൽ ലേബലിന് പരിധി മേഖലയ്ക്ക് പകരമാകാനാവില്ല.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
പ്രാമാണീകൃത എൻക്രിപ്ഷൻ യഥാർത്ഥത്തിൽ എന്ത് മാറ്റുന്നു
TLS 1.3 പ്രാമാണീകൃത എൻക്രിപ്ഷൻ നിർബന്ധമാക്കുന്നു, അത് പഴയ MAC-then-encrypt നിർമ്മാണം ഓപ്ഷണലായി വെക്കാതെ പ്രോട്ടോക്കോളിൽ നിന്ന് നീക്കം ചെയ്യുന്നു. IPsec ESP-യിലും അത്ര കാലമായി പ്രാമാണീകൃത എൻക്രിപ്ഷൻ സ്യൂട്ടുകൾ ഉണ്ട്, AES-GCM അതിന്റെ സ്വന്തം RFC-യിൽ നിർവചിച്ചിരിക്കുന്നു. രണ്ട് കുടുംബങ്ങളിലും ഉറപ്പ് കുടുംബനാമത്തിൽ നിന്നല്ല, ചർച്ച ചെയ്ത സ്യൂട്ടിൽ നിന്നാണ് വരുന്നത്, അതുകൊണ്ടാണ് മേഖലപ്പട്ടിക പതിപ്പിൽ തുടങ്ങുന്നത്. സ്യൂട്ട് പേര് പറയാനാകാത്ത അവലോകകന് വിലയിരുത്താൻ ഒന്നുമില്ല.
അതുകൊണ്ടാണ് ചരിത്രപരമായ താരതമ്യം തെറ്റായ വഴിക്ക് നയിക്കുന്നത്. CBC സ്യൂട്ടുമായി പഴയ TLS പതിപ്പിൽ പിൻ ചെയ്ത വിന്യാസവും AEAD സ്യൂട്ടുമായി TLS 1.3 പ്രവർത്തിപ്പിക്കുന്ന വിന്യാസവും ഒരേ സുരക്ഷാ നിലയല്ല, രണ്ടും TLS VPN ആണെങ്കിലും. അതേ വിഭജനം IPsec വശത്ത് ആധുനിക ESP സ്യൂട്ടും പഴയ സംയോജനവും തമ്മിലും ഉണ്ട്.
നിങ്ങൾ ഉദ്ദേശിച്ച കോൺഫിഗറേഷനല്ല, ചർച്ച ചെയ്ത മൂല്യങ്ങൾ വായിക്കുക. താഴെയുള്ള കമാൻഡുകൾ ഒരു സജീവ അന്ത്യബിന്ദുവും സജീവ തുരങ്കവും യഥാർത്ഥത്തിൽ എന്തിൽ യോജിച്ചു എന്ന് കാണിക്കുന്നു.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasഅന്ത്യബിന്ദു TLS 1.3-ൽ ചർച്ച ചെയ്യാൻ താൽപ്പര്യപ്പെടുന്നില്ലെങ്കിൽ, അത് ഒരു കണ്ടെത്തലാണ്, മുൻഗണനയല്ല. തുരങ്കം നിങ്ങൾ പ്രതീക്ഷിക്കാത്ത സ്യൂട്ട് പട്ടികപ്പെടുത്തിയാൽ, പ്രധാന കോൺഫിഗറേഷൻ സഹയാത്രികർ തിരഞ്ഞെടുത്തതാണ്, ടെംപ്ലേറ്റിലുള്ളതല്ല.
സഹയാത്രിക തിരിച്ചറിയൽ വേറെ ചോദ്യമാണ്
സ്ഥിരീകരിച്ച സഹയാത്രികനില്ലാതെ എൻക്രിപ്ഷൻ ട്രാഫിക്കിനെ നിരീക്ഷകരിൽ നിന്ന് സംരക്ഷിച്ച് കണക്ഷന് ഉത്തരം നൽകിയവർക്ക് ഏൽപ്പിക്കുന്നു. സഹയാത്രിക പ്രാമാണീകരണം ഏത് തിരിച്ചറിയൽ പ്രതീക്ഷിക്കുന്നു, ഏത് വിശ്വാസ വസ്തു അത് സ്ഥിരീകരിക്കുന്നു, ഉത്തരം ഒത്തുപോകാത്തപ്പോൾ ക്ലയന്റ് എങ്ങനെ പെരുമാറുന്നു എന്ന് ചോദിക്കുന്നു. സർട്ടിഫിക്കറ്റ് ശൃംഖല, പിൻ ചെയ്ത കീ, മുൻകൂട്ടി പങ്കിട്ട രഹസ്യം എന്നിവ മൂന്ന് വ്യത്യസ്ത ഉത്തരങ്ങളാണ്, മൂന്ന് വ്യത്യസ്ത പ്രവർത്തന ചെലവുകളോടെ.
പിന്നീട് ഉപയോക്താവിനെയോ ഉപകരണത്തെയോ കുറിച്ച് അതേ ചോദ്യങ്ങൾ ചോദിക്കുക. യന്ത്രത്തെ പ്രാമാണീകരിച്ച് ഏത് ഉപയോക്താവിനെയും പ്രവേശിപ്പിക്കുന്ന ഗേറ്റ്‌വേ, അല്ലെങ്കിൽ നേരെ മറിച്ച്, എഴുതേണ്ടതും ഊഹിക്കാൻ പാടില്ലാത്തതുമായ ഒരു പ്രത്യേക നിലപാട് ഉണ്ട്. പ്രവേശനത്തിന് ശേഷം പ്രയോഗിക്കുന്ന വിഭവാനുമതികൾ അതേ മേഖലയുടെ ഭാഗമാണ്, കാരണം പ്രാമാണീകരണം അധികാരമല്ല.
ഹോസ്റ്റ്നാമും സർട്ടിഫിക്കറ്റ് പരിശോധനകളും നിലനിർത്തുന്നത് ലോഗിൻ വിൻഡോയുടെ പരിചയത്തേക്കാൾ പ്രധാനമാണ്. സ്ഥിരീകരണം അവഗണിക്കാൻ കോൺഫിഗർ ചെയ്ത ക്ലയന്റ് നിങ്ങളുടെ ഗേറ്റ്‌വേയെ വിശ്വസനീയമായ അനുകരണത്തിൽ നിന്ന് വേർതിരിക്കുന്ന ഏക ഘട്ടം നീക്കം ചെയ്തു.
ഉൽപ്പന്നം വെളിപ്പെടുത്തുന്ന അതിർത്തി
ക്ലയന്റില്ലാത്ത പോർട്ടൽ തിരഞ്ഞെടുത്ത ആപ്ലിക്കേഷൻ പ്രവർത്തനങ്ങൾ ഗേറ്റ്‌വേ വഴി പ്രോക്സി ചെയ്യുന്നു, അതിനാൽ ഉപയോക്താവ് നെറ്റ്വർക്കിലേക്കല്ല, ഇന്റർഫേസിലേക്കാണ് എത്തുന്നത്. പൂർണ്ണ-തുരങ്ക ക്ലയന്റ് അതിന്റെ വഴികളും ഫിൽട്ടറിംഗ് നയവും തിരഞ്ഞെടുക്കുന്നത് വഹിക്കുന്നു, അത് വളരെ വലിയ ഉപരിതലമാണ്. രണ്ടിനെയും പ്രോട്ടോക്കോൾ ശക്തിയിൽ താരതമ്യം ചെയ്യുന്നത് ആക്രമണകാരിക്ക് അവയിലൂടെ എത്താനാകുന്നതിലെ വ്യത്യാസം നഷ്ടപ്പെടുത്തുന്നു. ഒന്ന് ആപ്ലിക്കേഷൻ ഇന്റർഫേസും മറ്റൊന്ന് റൂട്ട് ചെയ്ത നെറ്റ്വർക്കും വെളിപ്പെടുത്തുന്നു, രണ്ടും വ്യത്യസ്ത അവലോകനങ്ങൾ ആവശ്യപ്പെടുന്നു.
ഏത് സേവനമാണ് വെളിപ്പെടുത്തിയിരിക്കുന്നത്, ഏത് പ്രവർത്തനങ്ങൾക്കാണ് അധികാരം, ഗേറ്റ്‌വേ സ്വയം എന്ത് കേൾക്കുന്നു എന്ന് ചോദിക്കുക. ഉപയോക്തൃ പോർട്ടലിന്റെ അതേ വിലാസത്തിൽ നിന്ന് എത്താവുന്ന മാനേജ്മെന്റ് ഇന്റർഫേസ് ഒരു വിന്യാസ കണ്ടെത്തലാണ്, ഒരു പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുപ്പും അതിന് പകരമാകില്ല.
പ്രതി-ആപ്ലിക്കേഷൻ പരിധി ഉപരിതലം കൂടുതൽ ചുരുക്കുന്നു, തുരങ്കം വീഴുമ്പോൾ പരാജയ സ്വഭാവവും മാറ്റുന്നു. പൂർണ്ണ-തുരങ്ക എത്തിച്ചേരൽ അനുമാനിക്കുന്ന രൂപകൽപ്പന പ്രതി-ആപ്പ് രൂപകൽപ്പനയ്ക്ക് അറിയാത്ത രീതികളിൽ തകരും, പിന്തുണാ ഭാരം അതിനെ പിന്തുടരും.
പരാജയ ഫലവും ജീവിതചക്രവും തീരുമാനിക്കുക
പ്രാമാണീകരണമോ സംരക്ഷണമോ ലഭ്യമല്ലാത്തപ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്നത് അവലോകനത്തിൽ പെടുന്ന നയ തീരുമാനമാണ്. തടഞ്ഞ ഫലവും പ്രഖ്യാപിക്കാത്ത നേരിട്ടുള്ള പിന്മാറ്റവും വ്യത്യസ്ത പരിണിതഫലങ്ങൾ ഉണ്ടാക്കുന്നു, വ്യത്യാസം ഫീച്ചർ പട്ടികയിൽ അദൃശ്യമാണ്. ഉദ്ദേശിച്ച സ്വഭാവം അത് സംരക്ഷിക്കുന്ന വിഭവത്തിന് അരികെ രേഖപ്പെടുത്തുക.
ഗേറ്റ്‌വേയുടെ പാച്ചും പിന്തുണാ ജീവിതചക്രവും, അതിന്റെ സജീവമാക്കിയ ബാഹ്യ സവിശേഷതകളും ക്ലയന്റുകൾക്കുള്ള അപ്‌ഡേറ്റ് പാതയും ഉൾപ്പെടുത്തുക. ശരിയായ പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുപ്പ് മോശമായി വിന്യസിച്ച സേവനത്തെ സുരക്ഷിതമാക്കുന്നില്ല, മിക്ക സംഭവങ്ങളും സ്യൂട്ടിലല്ല, ആ വിടവിലാണ് ജീവിക്കുന്നത്.
അഞ്ച് മേഖലകൾ, പരാജയ നയം, ജീവിതചക്ര ഉടമ എന്നിവ ഒരു പേജിൽ എഴുതുക. ആ പേജ് ഒരു അവലോകനമാണ്; പ്രോട്ടോക്കോൾ കുടുംബങ്ങളുടെ താരതമ്യം ഒരു അഭിപ്രായമാണ്.