ACK പാക്കറ്റിലെ conntrack NEW: അത് എന്താണ് തെളിയിക്കാത്തത്

NEW എന്ന് അടയാളപ്പെടുത്തിയ ACK എന്നാൽ ട്രാക്കറിന് പൊരുത്തമുള്ള അവസ്ഥ ഇല്ലായിരുന്നു എന്നാണ്, VPN സെഷൻ തുറന്നു എന്നല്ല. hook, tuple, ക്യാപ്ചർ വിൻഡോ വായിക്കുക.

ഫയർവാൾ ലോഗിൽ നിങ്ങൾ പ്രതീക്ഷിക്കാത്ത ഒരു വരിയുണ്ട്: ഒരു ACK പാക്കറ്റ്, conntrack അവസ്ഥ NEW, നിങ്ങളുടേതല്ലാത്ത ഉറവിട വിലാസം, ലക്ഷ്യ പോർട്ട് തുറന്നിരിക്കുന്നു. ആരും അനുവദിക്കാത്ത പുതിയ ഇൻബൗണ്ട് കണക്ഷനായി ഇത് വായിക്കാനാണ് പ്രലോഭനം. ഈ വരി യഥാർത്ഥത്തിൽ പറയുന്നത് കൂടുതൽ ഇടുക്കമുള്ളതാണ്: ആ പാക്കറ്റ് ഈ hook-ൽ എത്തിയപ്പോൾ ട്രാക്കറിന് പൊരുത്തമുള്ള അവസ്ഥ ഇല്ലായിരുന്നു, പാക്കറ്റ് ACK വഹിച്ചിരുന്നു. ഇവ രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളെക്കുറിച്ചുള്ള രണ്ട് വസ്തുതകളാണ്, ഒന്നും പൂർണ്ണ ഹസ്തദാന രേഖയല്ല. നിഗമനത്തിലെത്തുന്നതിന് മുൻപ് ഞാൻ പിന്തുടരുന്ന ക്രമം ഇതാണ്.

വിധിയിൽ നിന്നല്ല, പാക്കറ്റിൽ നിന്ന് തുടങ്ങുക

വ്യാഖ്യാനിക്കുന്നതിന് മുൻപ് നിരീക്ഷണങ്ങൾ വേർതിരിക്കുക. TCP ഫ്ലാഗുകൾ ഈ പാക്കറ്റിനെ വിവരിക്കുന്നു, ട്രാക്കറിന്റെ അവസ്ഥ ആ hook-ൽ അതിന് എന്തറിയാമായിരുന്നു എന്ന് വിവരിക്കുന്നു, നിങ്ങളുടെ ക്യാപ്ചർ നിങ്ങൾ രേഖപ്പെടുത്തിയ വിൻഡോ മാത്രം വിവരിക്കുന്നു.

ഈ മൂന്നും കൂട്ടിക്കലർത്തുന്നതാണ് ഒരു ACK “ദാതാവ് ആരെയോ അകത്തേക്ക് വിട്ടു” ആകുന്ന വഴി.

hook-ൽ NEW യഥാർത്ഥത്തിൽ എന്താണ് അർത്ഥമാക്കുന്നത്

iptables conntrack പൊരുത്തം NEW-യെ ഒരു കണക്ഷൻ ആരംഭിക്കുന്ന പാക്കറ്റ് ആയി, അല്ലെങ്കിൽ ഇരുദിശകളിലും ട്രാഫിക് ഇതുവരെ കണ്ടിട്ടില്ലാത്ത കണക്ഷനുമായി ബന്ധപ്പെട്ട പാക്കറ്റ് ആയി രേഖപ്പെടുത്തുന്നു. ESTABLISHED എന്നാൽ ട്രാക്കർ ഇരുദിശകളിലും പാക്കറ്റുകൾ കണ്ടു എന്നാണ്. രണ്ട് നിർവചനങ്ങളും പാക്കറ്റ് SYN ആയിരുന്നു എന്നോ ചരിത്രമില്ലാതെ വന്നു എന്നോ പറയുന്നില്ല.

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

അയഞ്ഞ ട്രാക്കിംഗ് മിക്ക ACK അത്ഭുതങ്ങളും വിശദീകരിക്കുന്നു

കേർണൽ രേഖപ്പെടുത്തുന്നു nf_conntrack_tcp_loose, ഇത് ട്രാക്കറിന് തുടക്കം കാണാത്ത TCP കണക്ഷനുകൾ ഏറ്റെടുക്കാൻ അനുവദിക്കുന്നു. സെറ്റിംഗ് അതിന്റെ സ്വതവേയുള്ള മൂല്യത്തിൽ ആയിരിക്കുമ്പോൾ, ഒഴുക്കിന്റെ മധ്യത്തിൽ നിന്നുള്ള ACK സ്ഥാപിത ഒഴുക്കായി സ്വീകരിക്കാം. അത് ഓഫാക്കിയാൽ അതേ പാക്കറ്റ് NEW-ക്ക് പകരം INVALID ആയി വർഗ്ഗീകരിക്കാനുള്ള സാധ്യത കൂടും. രണ്ട് ഫലങ്ങളും ട്രാക്കറിന്റെ നിയമങ്ങൾ വിവരിക്കുന്നു, ആപ്ലിക്കേഷന്റെ ചരിത്രമല്ല.

അതിനാൽ ലേബലിൽ സിദ്ധാന്തം കെട്ടുന്നതിന് മുൻപ് ആ സെറ്റിംഗ് പരിശോധിക്കുക.

വിരസമായ കാരണങ്ങൾ ഈ ക്രമത്തിൽ ഒഴിവാക്കുക

ഞാൻ പിന്തുടർന്ന NEW-on-ACK സംഭവങ്ങളിൽ മിക്കതും ഇവയിലൊന്നിൽ അവസാനിച്ചു, എല്ലാം പരിശോധിക്കാൻ വിലകുറവാണ്:

  • conntrack പട്ടിക ഫ്ലഷ് ചെയ്തു, അല്ലെങ്കിൽ ട്രാക്കർ പുനരാരംഭിച്ചു.
  • ഹോസ്റ്റ് റീബൂട്ട് ചെയ്തു, അല്ലെങ്കിൽ ഒഴുക്ക് മറ്റൊരു namespace അല്ലെങ്കിൽ ഉപകരണത്തിലേക്ക് മാറി.
  • അസമമായ റൂട്ടിംഗ് SYN നിങ്ങൾ ക്യാപ്ചർ ചെയ്യാത്ത പാതയിലൂടെ പുറത്തയച്ചു.
  • NAT tuple മാറ്റിയെഴുതി, അതിനാൽ എൻട്രി ഇനി നിങ്ങൾ വായിച്ചതുമായി പൊരുത്തപ്പെടുന്നില്ല.
  • ക്യാപ്ചർ വൈകി തുടങ്ങി, തുടക്കം ഒരിക്കലും കണ്ടില്ല.

ഇവയോരോന്നും മുൻപത്തെ പാക്കറ്റുകളെ ട്രാക്കറിന്റെ കാഴ്ചയിൽ നിന്ന് നീക്കി പിന്നീടുള്ളവയെ അതേപടി നിർത്തുന്നു. റീബൂട്ടോ പട്ടിക ഫ്ലഷോ uptime-ൽ നിന്നും ലോഗുകളിൽ നിന്നും സ്ഥിരീകരിക്കാൻ എളുപ്പമാണ്. അസമമായ റൂട്ടിംഗ് ഏകദിശാ ക്യാപ്ചറായി കാണപ്പെടുന്നു. NAT വഞ്ചകനാണ്, കാരണം ട്രാക്കർ സൂക്ഷിച്ച tuple ലോഗിൽ അച്ചടിച്ച tuple അല്ല.

മുന്നോട്ട് പോകുന്നതിന് മുൻപ് ഇവയിൽ ഏതൊക്കെ ഒഴിവാക്കി, എങ്ങനെ എന്ന് എഴുതുക.

tuple, ഇന്റർഫേസ്, hook എന്നിവ വായിക്കുക

conntrack എൻട്രി വിലാസങ്ങൾ, പോർട്ടുകൾ, പ്രോട്ടോക്കോൾ എന്നിവയാൽ കീ ചെയ്യപ്പെടുന്നു, അതിനാൽ ഏത് വിവർത്തനവും ഏത് എൻട്രി പൊരുത്തപ്പെടുന്നു എന്നത് മാറ്റുന്നു. ഇന്റർഫേസും hook-ഉം രേഖപ്പെടുത്തുക, കാരണം തെറ്റായ ഇന്റർഫേസിലോ മറ്റൊരു ചെയിനിന് ശേഷമോ കാണുന്ന പാക്കറ്റ് പാത ഡയഗ്രാമിൽ ഉള്ളതല്ല എന്ന് പറയുന്നു. സംഭവം VPN-മായി ബന്ധപ്പെട്ടതാണെങ്കിൽ, നിങ്ങൾ ഉള്ളിലെ പാക്കറ്റാണോ പുറത്തെ വാഹകനാണോ നോക്കുന്നതെന്ന് തീരുമാനിക്കുക. തുടർന്ന് അതേ അഞ്ച് ഭാഗ tuple-ക്ക് ഗേറ്റ്വേ രേഖപ്പെടുത്തിയതുമായി താരതമ്യം ചെയ്യുക.

ഒരേ ഒഴുക്കിന്റെ രണ്ട് വിരുദ്ധ കാഴ്ചകൾ ഓരോന്നിനെക്കാളും കൂടുതൽ വിവരം നൽകുന്നു.

എപ്പോഴാണ് എസ്കലേറ്റ് ചെയ്യേണ്ടത്

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

തുടർന്ന് ഒരു പാക്കറ്റിനെ മുഴുവൻ സെഷൻ പോലെ കാണിച്ച ദൃശ്യതാ വിടവ് അടയ്ക്കുക.

അനുബന്ധ ലേഖനങ്ങൾ