ഒരു പാക്കറ്റ് ക്യാപ്ചറിൽ ആദ്യ IKEv2 കൈമാറ്റം എങ്ങനെ വായിക്കാം

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

നിങ്ങൾ തുടക്ക കൈമാറ്റം കാണുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക

IKEv2 ചർച്ച ആരംഭിക്കുന്നത് IKE_SA_INIT-ൽ, കൈമാറ്റ തരം 34, സന്ദേശ ഐഡി 0. സംരംഭകൻ പൂജ്യമല്ലാത്ത SPI തിരഞ്ഞെടുക്കുന്നു, പ്രതികരിക്കുന്നയാളുടെ SPI ആ ആദ്യ അഭ്യർത്ഥനയിൽ പൂജ്യവും പ്രതികരണത്തിൽ പൂജ്യമല്ലാത്തതുമാണ്. ഈ മൂന്ന് വസ്തുതകൾ പുതിയ ശ്രമത്തെ താക്കോൽ പുതുക്കലിൽ നിന്നോ ക്യാപ്ചറിന്റെ മുകളിൽ യാദൃശ്ചികമായി ഇരിക്കുന്ന IKE_AUTH സന്ദേശത്തിൽ നിന്നോ വേർതിരിക്കുന്നു.

ഹെഡർ ഫീൽഡുകൾ വായിക്കാവുന്നതാണ്, നിർദ്ദേശം, താക്കോൽ കൈമാറ്റം, nonce എന്നിവയുടെ പേലോഡുകളും. വായിക്കാവുന്നത് എന്നാൽ സത്യാവിഷ്കരിച്ചത് എന്നർത്ഥമില്ല: ഈ ഘട്ടത്തിൽ ഒരു വശവും ഐഡന്റിറ്റി തെളിയിച്ചിട്ടില്ല, Diffie-Hellmanന്റെ സ്വകാര്യ മൂല്യം ഒരിക്കലും ലൈനിൽ പ്രത്യക്ഷപ്പെടുന്നില്ല.

ഡീകോഡ് പാനൽ സ്ക്രോൾ ചെയ്യുന്നതിന് പകരം ഫീൽഡുകൾ പട്ടികയായി അടിക്കുക, കാരണം വീണ്ടും അയയ്ക്കലുകളും പൊരുത്തപ്പെടാത്ത SPIകളും നിരകളിൽ വ്യക്തമാകും.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

ഔട്ട്പുട്ട് ജോടിയായി വായിക്കുക. സന്ദേശ ഐഡി 0 ഉള്ള ഒരു അഭ്യർത്ഥനയ്ക്ക് ശേഷം അതേ ഐഡിയും പൂജ്യമല്ലാത്ത പ്രതികരിക്കുന്നയാളുടെ SPIയും വഹിക്കുന്ന പ്രതികരണം ഒരു കൈമാറ്റമാണ്, അഭ്യർത്ഥന വീണ്ടും അയച്ചതിനാൽ അത് മൂന്ന് തവണ പ്രത്യക്ഷപ്പെട്ടാലും. ഒരേപോലെയുള്ള മൂന്ന് അഭ്യർത്ഥനകൾ മൂന്ന് ലോഗിനുകളല്ല, അങ്ങനെ കണക്കാക്കുന്നതാണ് ക്ലയന്റ് ലൂപ്പിൽ കറങ്ങുന്നു എന്ന നിഗമനത്തിലേക്ക് എത്തുന്നത്; യഥാർത്ഥത്തിൽ അത് ക്ഷമയോടെ മാത്രമാണ്. സന്ദേശ ഐഡി പ്രകാരം, പിന്നീട് സമയമുദ്ര പ്രകാരം അടുക്കുക, മുഴുവൻ സംഭാഷണവും ചെറിയ ശ്രമപ്പട്ടികയായി ചുരുങ്ങും.

വിജയം വായിക്കുന്നതിന് മുമ്പ് നിരാകരണം വായിക്കുക

പ്രതികരണം സ്വയമേവയുള്ള പുരോഗതിയല്ല. പ്രതികരിക്കുന്നയാൾ cookie അറിയിപ്പ് നൽകി സംരംഭകൻ വീണ്ടും ശ്രമിക്കുമെന്ന് പ്രതീക്ഷിക്കാം, അല്ലെങ്കിൽ പകരം സ്വീകരിക്കുന്ന ഒരു ഗ്രൂപ്പിനെ പേരെടുത്ത് പറയുന്ന INVALID_KE_PAYLOAD നൽകാം. രണ്ടും ശരിയായി രൂപപ്പെടുത്തിയ IKE സന്ദേശങ്ങളായി എത്തുന്നു, പാക്കറ്റുകൾ മാത്രം എണ്ണുന്ന ഫിൽട്ടറിന് രണ്ടും പൂർത്തിയായ കൈമാറ്റം പോലെ തോന്നുന്നു.

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

എൻക്രിപ്റ്റ് ചെയ്ത ഐഡന്റിറ്റിയും സത്യാവിഷ്കരണ പേലോഡുകളും വഹിക്കുന്നത് IKE_AUTH മാത്രമാണ്, അതായത് രണ്ടാം കൈമാറ്റം. അതിനാൽ പൂർത്തിയായ IKE_SA_INIT പറയുന്നത് വശങ്ങൾ അൽഗോരിതങ്ങളിലും ഉരുത്തിരിഞ്ഞ താക്കോലുകളിലും യോജിക്കുന്നു എന്നാണ്, ക്രെഡൻഷ്യലുകൾ സ്വീകരിക്കുമോ എന്നതിനെക്കുറിച്ച് ഒന്നുമല്ല. അവിടെയും രണ്ട് സന്ദേശങ്ങൾ പ്രതീക്ഷിക്കുക, സെഷൻ താക്കോലുകളില്ലാതെ രണ്ടും അതാര്യമായിരിക്കും എന്ന് പ്രതീക്ഷിക്കുക.

4500 പോർട്ട് ഒരു പ്രോട്ടോക്കോൾ അല്ല

തുടക്ക കൈമാറ്റം സാധാരണയായി UDP 500 വഹിക്കുന്നു. NAT കണ്ടെത്തൽ പ്രവർത്തിച്ചതിന് ശേഷം IKE 4500 ലേക്ക് മാറുന്നു, ഓരോ സന്ദേശത്തിനും മുമ്പ് നാല് ബൈറ്റ് പൂജ്യമുള്ള ESP അല്ലാത്ത അടയാളം ചേർക്കുന്നു. അതേ പോർട്ടിലെ എൻകാപ്സുലേറ്റ് ചെയ്ത ESP പകരം പൂജ്യമല്ലാത്ത ESP SPIയിൽ തുടങ്ങുന്നു, ഒരു ബൈറ്റ് NAT keepalive മറ്റൊന്നും സംഭവിക്കാത്തപ്പോൾ പ്രത്യക്ഷപ്പെടുന്ന മൂന്നാം രൂപമാണ്.

പോർട്ട് മാത്രം ഒത്തുനോക്കുന്ന ഫിൽട്ടർ മൂന്നിനെയും കലർത്തുന്നു, അതുകൊണ്ടാണ് "4500-ൽ ട്രാഫിക് ഉണ്ട്" എന്നത് വളരെ കുറച്ച് മാത്രം തീരുമാനിക്കുന്നത്. ദൂരെയുള്ള അറ്റത്തെക്കുറിച്ച് എന്തെങ്കിലും നിഗമനം എടുക്കുന്നതിന് മുമ്പ് കാഴ്ച പ്രോട്ടോക്കോൾ പ്രകാരം വിഭജിക്കുക.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

നിശ്ശബ്ദത നിരീക്ഷണ ബിന്ദുവിനെ വിവരിക്കുന്നു

പ്രതികരണമില്ലാത്ത അഭ്യർത്ഥനകൾ കൃത്യമായി ഒരു കാര്യം സ്ഥാപിക്കുന്നു: ആ ക്യാപ്ചർ ബിന്ദുവിൽ ഒരു പ്രതികരണവും പ്രത്യക്ഷപ്പെട്ടില്ല. ഫിൽട്ടറിംഗ്, പ്രതികരണം മറ്റൊരിടത്തേക്ക് അയയ്ക്കുന്ന റൂട്ട്, എത്തിച്ചേരാനാകാത്ത പ്രതികരിക്കുന്നയാൾ, അല്ലെങ്കിൽ നിർദ്ദേശം ഇഷ്ടപ്പെടാത്ത പ്രതികരിക്കുന്നയാൾ — എല്ലാം ഒരേ ശൂന്യഫലം നൽകുന്നു, പൊതുവായ UDP പരിശോധന അവയെ വേർതിരിക്കില്ല.

ICMP എത്തിച്ചേരാനാകായ്മ മറ്റൊരു തരം തെളിവാണ്. അതിനുള്ളിലെ ഉദ്ധരിച്ച പാക്കറ്റ് വായിച്ച് ഏത് ഉപകരണമാണ് അത് പുറപ്പെടുവിച്ചതെന്ന് കണ്ടെത്തുക, കാരണം റൂട്ടറിന്റെ ഭരണപരമായ നിരാകരണം ദൂരെയുള്ള അറ്റത്തുനിന്നുള്ള സത്യാവിഷ്കൃത പിശകല്ല.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

വായിക്കാൻ അനുവാദമുള്ളിടത്ത് അതേ ശ്രമം സെർവർ വശത്തെ ലോഗുകളുമായി പൊരുത്തപ്പെടുത്തുക. അഭ്യർത്ഥന എത്തിയോ, സേവനം പ്രതികരിച്ചോ, പ്രതികരണം എവിടെ നിന്നോ? ആ മൂന്ന് ഉത്തരങ്ങൾ നിങ്ങളെ പാതയുടെ പ്രശ്നത്തിലേക്കോ നയത്തിന്റെ പ്രശ്നത്തിലേക്കോ അയയ്ക്കുന്നു, നാലാം തവണ ക്രെഡൻഷ്യലുകൾ മാറ്റുന്നതിനേക്കാൾ കുറവ് ചെലവാണ്.