AH അതോ ESP? പാക്കറ്റ് എന്തിനെ സംരക്ഷിക്കണം എന്നതിൽ നിന്ന് തീരുമാനിക്കുക

രണ്ട് IPsec നിർദ്ദേശങ്ങൾ ഒരേ SHA അടിസ്ഥാനമാക്കിയ സമഗ്രതാ അൽഗോരിതം പറഞ്ഞിട്ടും വ്യത്യസ്ത സംരക്ഷണ പ്രോട്ടോക്കോളുകൾ ആവശ്യപ്പെടാം; AH ഉം ESP ഉം ഒരേ പ്രമാണീകരണ ക്രമീകരണത്തിന്റെ രണ്ട് വർണ്ണരൂപങ്ങളല്ല. ആദ്യം പ്രോട്ടോക്കോൾ, പിന്നെ അതിന്റെ അൽഗോരിതങ്ങൾ, പിന്നെ അതിന്റെ മോഡ് വായിക്കുക, മിക്ക ആശയക്കുഴപ്പവും മാറും. AH പാക്കറ്റ് പരിശോധിക്കുന്നു, യാത്രയിൽ മാറാത്ത IP ഹെഡർ ഫീൽഡുകൾ ഉൾപ്പെടെ, അതേസമയം ESP താൻ ഉൾക്കൊള്ളിക്കുന്നത് പരിശോധിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത് പുറം ഹെഡർ വെറുതെ വിടുന്നു. ആ വ്യത്യാസമാണ് ഏത് hash നാമത്തേക്കാളും കൂടുതൽ വിന്യാസങ്ങൾ തീരുമാനിക്കുന്നത്.

AH ഉൾക്കൊള്ളുന്നതും ESP ഉൾക്കൊള്ളാത്തതും

AH സമഗ്രത, ഡാറ്റയുടെ ഉത്ഭവ പ്രമാണീകരണം, താൻ നിർവചിക്കുന്ന ആവർത്തന പ്രതിരോധ സേവനം എന്നിവ നൽകുന്നു, രഹസ്യത ഒട്ടുമില്ല. അതിന്റെ പരിധിയിൽ മുകൾ പാളിയിലെ ഡാറ്റയും, അതിന്റെ നിയമങ്ങൾ മാറ്റമില്ലാത്തതായി കണക്കാക്കുന്ന IP ഹെഡർ ഫീൽഡുകളും ഉൾപ്പെടുന്നു, അതായത് ESP ട്രാൻസ്പോർട്ട് മോഡിൽ പുറത്തു വിടുന്ന ഭാഗം തന്നെ. IP ഹെഡർ തന്നെ പ്രമാണീകരിക്കണം എന്ന് ആവശ്യകത പറഞ്ഞാൽ അതിന് ഉത്തരം നൽകുന്ന പ്രോട്ടോക്കോൾ AH ആണ്.

ഈ പരിധിയാണ് AH യാഥാർഥ്യത്തിൽ ദുർബലമാകാനുള്ള കാരണവും. TTL, ഹെഡർ ചെക്സം, ചില ഓപ്ഷനുകൾ തുടങ്ങിയ മാറുന്ന ഫീൽഡുകൾ പ്രമാണീകരിക്കാൻ കഴിയില്ല, കാരണം റൗട്ടറുകൾക്ക് അവ വീണ്ടും എഴുതാം, അതിനാൽ പരിശോധന കണക്കാക്കുന്നതിന് മുൻപ് പ്രോട്ടോക്കോൾ അവ പൂജ്യമാക്കുന്നു. അതിനാൽ വിലാസങ്ങൾ വീണ്ടും എഴുതുന്ന എന്തും നയം മാത്രമല്ല, കണക്കുകൂട്ടലും തകർക്കുന്നു.

NAT തിരഞ്ഞെടുപ്പിനെ നിയന്ത്രണമാക്കി മാറ്റുന്നു

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

ഉണ്ടെങ്കിൽ AH ഒഴിവാകും, സംഭാഷണം ESP യിലേക്കും അതിന്റെ അൽഗോരിതം തിരഞ്ഞെടുപ്പിലേക്കും നീങ്ങും. ഇത് മുൻഗണനയല്ല നിയന്ത്രണമാണ്, അതിനാൽ അതിന്റെ സ്ഥാനം തീരുമാനത്തിന്റെ തുടക്കത്തിലാണ്, അവസാനത്തിലല്ല.

മോഡ് ചോദ്യത്തെ ഗുണിക്കുന്നു

ESP ട്രാൻസ്പോർട്ട് മോഡിൽ മുകൾ പാളിയുടെ ഭാരം സംരക്ഷിച്ച് IP ഹെഡർ വെറുതെ വിടുന്നു; ടണൽ മോഡിൽ അകത്തെ IP ഹെഡർ ഉൾപ്പെടെ മുഴുവൻ അകത്തെ പാക്കറ്റും ഉൾക്കൊള്ളിച്ച് സംരക്ഷിക്കുന്നു. AH യ്ക്കും അതേ രണ്ട് മോഡുകളുണ്ട്, അതിനാൽ AH അല്ലെങ്കിൽ ESP എന്നത് ഏതെങ്കിലും അൽഗോരിതം തിരഞ്ഞെടുക്കുന്നതിന് മുൻപ് യഥാർഥത്തിൽ നാല് സംയോജനങ്ങളാണ്.

സംയുക്ത മോഡിലെ ESP അൽഗോരിതങ്ങൾ പിന്നീട് രണ്ടാം പ്രോട്ടോക്കോളില്ലാതെ സമഗ്രത തീരുമാനിക്കുന്നു. AES-GCM ഉം ChaCha20-Poly1305 ഉം ഒരേ നിർമ്മിതിയിൽ പ്രമാണീകരണവും എൻക്രിപ്ഷനും ചെയ്യുന്നു, അതിനാൽ മുകളിൽ AH ചേർക്കുന്നത് ഒന്നും നേടുന്നില്ല, പക്ഷേ മറ്റൊരു ഹെഡറും മറ്റൊരു ചർച്ചയും ചെലവാകുന്നു. വാസ്തുവിദ്യ AH യും ESP യും ഒരുമിച്ച് അനുവദിക്കുന്നു, പ്രായോഗിക ചോദ്യം നിങ്ങളുടെ ഗേറ്റ്‌വേയും പതിപ്പും ഈ സംയോജനം പിന്തുണയ്ക്കുന്നുണ്ടോ എന്നും പിന്നീട് ആർക്കെങ്കിലും അത് പരിപാലിക്കാനാകുമോ എന്നുമാണ്.

AH മാത്രത്തിനുള്ള സത്യസന്ധമായ പകരം

സമഗ്രത മാത്രമുള്ള ESP രൂപം അൽഗോരിതം നിലനിർത്തുകയും എൻക്രിപ്ഷൻ അവകാശവാദം വ്യാജമാക്കുന്നതിന് പകരം ഉപേക്ഷിക്കുകയും ചെയ്യുന്നു, അത് NAT കടക്കുന്നു. രഹസ്യതയില്ലാത്ത പ്രമാണീകരണം വേണ്ടിയിരുന്നതിനാൽ പഴയ രൂപകൽപ്പന AH ഉപയോഗിച്ചിരുന്നെങ്കിൽ, ആ രൂപമാണ് നേരിട്ടുള്ള പരിഭാഷ, കുറിപ്പ് ചേർത്ത എൻക്രിപ്റ്റഡ് ടണലല്ല.

നിർദ്ദേശത്തിൽ ESP കാണുന്നതും എൻക്രിപ്ഷന്റെ തെളിവല്ല. എൻക്രിപ്ഷൻ അൽഗോരിതം വായിക്കുക: NULL എന്ന എൻട്രി സമഗ്രത മാത്രം, സംയുക്ത മോഡ് എൻട്രി രണ്ടും.

മൂന്ന് ചോദ്യങ്ങളിൽ തീരുമാനിക്കുക

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

പിന്നീട് സ്വീകരിച്ചത് പരിശോധിക്കുക, നിർദ്ദേശിച്ചതല്ല. ip xfrm state ഇൻസ്റ്റാൾ ചെയ്ത അസോസിയേഷന്റെ പ്രോട്ടോക്കോൾ, മോഡ്, അൽഗോരിതങ്ങൾ എന്നിവ കാണിക്കുന്നു, പൊരുത്തക്കേടുണ്ടെങ്കിൽ ഒന്നും ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല, അത് ഉദ്ദേശിച്ച സംരക്ഷണമില്ലാതെ ഉയരുന്ന ടണലിനേക്കാൾ വ്യക്തമായ പരാജയമാണ്.

പ്രമാണീകരണ പരാജയങ്ങൾ, സെലക്ടർ പരിധി, റൂട്ടിംഗ് പിശകുകൾ എന്നിവ ഈ തിരഞ്ഞെടുപ്പിൽ നിന്ന് വേർതിരിച്ച് നിർത്തുക. അവ വ്യത്യസ്ത ലക്ഷണങ്ങൾ നൽകുന്നു, സെലക്ടർ പ്രശ്നത്തിന് പ്രോട്ടോക്കോളിനെ കുറ്റപ്പെടുത്തുന്നത് കാരണമില്ലാതെ hash മാറ്റി ഒരു ദിവസം ചെലവാക്കാനുള്ള വിശ്വസനീയ വഴിയാണ്.