IPsec-ന് മുകളിൽ ഡാറ്റാബേസ് ക്വറി തടയുന്നു: UDP പുനഃക്രമീകരണമോ TCP-യോ?
വ്യക്തമായ ഹാൻഡ്ഷേക്കിന് ശേഷം തടയുന്ന ക്വറി ടണലിന്റെ പാതയുടെ ഉള്ളിലേക്ക് വിരൽ ചൂണ്ടുന്നു. പാത ശരിയാക്കണോ 443-ലെ TCP-യിലേക്ക് മടങ്ങണോ എന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു.
TCP ഹാൻഡ്ഷേക്കിന് ശേഷം തടയുന്ന ക്വറി റൗട്ടിംഗ് പ്രശ്നമല്ല. റൂട്ടിലെ തകരാറുകൾ ഹാൻഡ്ഷേക്ക് പരാജയപ്പെടുത്തുന്നു, അതിനാൽ സ്ഥാപിതമായി പിന്നീട് നിശ്ശബ്ദമാകുന്ന സെഷൻ പാതയുടെ ഉള്ളിലേക്ക് വിരൽ ചൂണ്ടുന്നു: പരിശോധന, MTU, അല്ലെങ്കിൽ ടണലിന്റെ UDP പാക്കറ്റുകൾ എത്തുന്ന രീതി. നിങ്ങളുടെ മുന്നിലുള്ള തീരുമാനം ആ പാത ശരിയാക്കണോ ടണൽ TCP-യിലേക്ക് മാറ്റണോ എന്നതാണ്. മൂന്ന് വ്യവസ്ഥകൾ അത് തീരുമാനിക്കുന്നു, അവയൊന്നും ഡാറ്റാബേസിനെക്കുറിച്ചല്ല.
ടണലിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് തടസ്സം വർഗ്ഗീകരിക്കുക
നാല് ഫലങ്ങൾ ഉപയോക്താവിന് ഒരുപോലെ തോന്നുന്നു, എൻജിനിയറിന് തീർത്തും വ്യത്യസ്തമായ കാര്യങ്ങൾ അർത്ഥമാക്കുന്നു.
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
അവസാന രണ്ട് വരികൾ മാത്രമാണ് ടണലിൽ സമയം ചെലവിടുന്നത് ന്യായീകരിക്കുന്നത്. VPN വഴി നിരസിക്കപ്പെട്ട കണക്ഷൻ സാധാരണയായി ഡാറ്റാബേസ് loopback-ൽ മാത്രം കേൾക്കുന്നതാണ്, അത് ശ്രോതാവിന്റെ പ്രശ്നമാണ്, ഹാൻഡ്ഷേക്കിന് മുൻപുള്ള ടൈംഔട്ട് ഫിൽട്ടറോ റൂട്ടോ ആണ്. രണ്ടും എൻകാപ്സുലേഷൻ മാറ്റുന്നതുകൊണ്ട് മെച്ചപ്പെടുന്നില്ല.
വർഗ്ഗീകരണം ആദ്യം ടിക്കറ്റിൽ എഴുതുക. അതാണ് ഏറ്റവും വിലകുറഞ്ഞ ഘട്ടം, തിരയൽ ഇടത്തിന്റെ ഭൂരിഭാഗവും ഇല്ലാതാക്കുന്നു.
UDP-യും TCP-യും തമ്മിൽ തീരുമാനിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ
എൻകാപ്സുലേറ്റ് ചെയ്ത IPsec ട്രാഫിക് UDP-യിലൂടെ സഞ്ചരിക്കുന്നു, UDP പാതയ്ക്ക് ആരോടും പറയാതെ പുനഃക്രമീകരിക്കാനും വീഴ്ത്താനും സ്വാതന്ത്ര്യം നൽകുന്നു. പുനഃക്രമീകരണം പാക്കറ്റുകളെ ടണലിന്റെ ആവർത്തന-വിരുദ്ധ ജാലകത്തിന് പുറത്തേക്ക് തള്ളുമ്പോൾ അവ നിശ്ശബ്ദമായി ഒഴിവാക്കപ്പെടുന്നു, ഉള്ളിലെ TCP സെഷൻ കേവലം കാത്തിരിക്കുന്നു. വിജയകരമായ ഹാൻഡ്ഷേക്കിനും ഒരിക്കലും മടങ്ങാത്ത ക്വറിക്കും പിന്നിലെ സംവിധാനം ഇതാണ്.
പാത ശരിയാക്കുന്നതോ TCP-യിലേക്ക് മടങ്ങുന്നതോ മൂന്ന് കാര്യങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു. ഒന്ന്, പാതയിൽ യഥാർത്ഥ പാക്കറ്റ് നഷ്ടമുണ്ടോ, അതോ പുനഃക്രമീകരണം മാത്രമോ? രണ്ട്, പരിശോധന എവിടെ നടക്കുന്നു എന്ന് മാറ്റാൻ കഴിയുമോ, അല്ലെങ്കിൽ ഈ ടണൽ പുനഃക്രമീകരിക്കുന്ന ഘടകത്തിൽ നിന്ന് ഒഴിവാക്കാൻ കഴിയുമോ? മൂന്ന്, ജോലിഭാരം തടസ്സ മാതൃകയോട് സംവേദനക്ഷമമാണോ, ഉദാഹരണത്തിന് ഒരു ലിങ്ക് പങ്കിടുന്ന നിരവധി മൾട്ടിപ്ലെക്സ് സെഷനുകൾ?
ആദ്യ ഉത്തരം നഷ്ടമാണെങ്കിൽ, രണ്ടാമത്തേത് അല്ലെങ്കിൽ,443-ലെ TCP ആണ് പ്രായോഗിക ബദൽ. രണ്ടാമത്തെ ഉത്തരം അതെയെങ്കിൽ, പാത ശരിയാക്കി UDP നിലനിർത്തുക.
ആപ്ലിക്കേഷൻ പിശകല്ല, ഫയർവാൾ രേഖ വായിക്കുക
ആപ്ലിക്കേഷൻ ടൈംഔട്ട് റിപ്പോർട്ട് ചെയ്യുന്നു, അത് കാരണത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഫയർവാളിന്റെ സ്വന്തം ലോഗ് ആണ് ഡ്രോപ്പോ ബ്ലോക്കോ പ്രത്യക്ഷപ്പെടുന്ന സ്ഥലം, അതിനാൽ ഡാറ്റാബേസിന്റെയും ആപ്ലിക്കേഷന്റെയും വിലാസങ്ങൾ കൊണ്ട് ഫിൽട്ടർ ചെയ്ത് സ്വീകരണങ്ങൾക്കൊപ്പം ഡ്രോപ്പുകളും തിരയുക.ഭീഷണി പ്രതിരോധ ബ്ലേഡുകൾക്ക് ആപ്ലിക്കേഷൻ തലത്തിൽ പിശക് സൃഷ്ടിക്കാതെ പാക്കറ്റുകൾ ഒഴിവാക്കാം, അതാണ് തടയുന്ന ക്വറിയുടെ കൃത്യമായ രൂപം. ലോഗിലെ നിശ്ശബ്ദതയും വിവരമാണ്: അത് ലോഗ് ചെയ്യാത്ത എന്തോ ഒന്നിലേക്ക്, ഉദാഹരണത്തിന് പുനഃക്രമീകരണത്തിലേക്ക് വിരൽ ചൂണ്ടുന്നു.
ക്ലസ്റ്ററും പരിശോധിക്കുക. തെറ്റായി ക്രമീകരിച്ച ക്ലസ്റ്റർ ഒരു അംഗത്തിന്റെ സ്റ്റേറ്റ് ടേബിളിൽ സെഷൻ പിടിച്ചുവെക്കുമ്പോൾ പാക്കറ്റുകൾ മറ്റൊരു അംഗത്തിന്റെ പാതയിലൂടെ പോകാം, അതിനാൽ സ്റ്റേറ്റ് ഇല്ലാത്തിടത്ത് ഉത്തരങ്ങൾ എത്തുന്നു. അത്തരം തടസ്സങ്ങൾ ക്രമരഹിതമായി തോന്നുന്നു, ലോഡുമായി ബന്ധമില്ല.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ഇരു അറ്റങ്ങളും താരതമ്യം ചെയ്യുക, പാക്കറ്റ് എണ്ണമല്ല, എത്തിച്ചേരൽ ക്രമം താരതമ്യം ചെയ്യുക:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap443-ലെ TCP യഥാർത്ഥത്തിൽ നിങ്ങൾക്ക് എന്ത് ചെലവാക്കുന്നു
ടണൽ TCP-യിലേക്ക് മാറ്റുന്നത് പുനഃക്രമീകരണ ലക്ഷണം ഒഴിവാക്കുന്നു, കാരണം ഇടനില പെട്ടി ഇപ്പോൾ ക്രമീകരിച്ച സ്ട്രീം കാണുന്നു. അത് TCP-over-TCP-യും സൃഷ്ടിക്കുന്നു. പുറത്തെ കണക്ഷൻ ഉള്ളിലെ കണക്ഷൻ ഇതിനകം വീണ്ടും അയച്ചത് വീണ്ടും അയക്കുന്നു, ഒരു നഷ്ടം ഒരേസമയം എല്ലാ മൾട്ടിപ്ലെക്സ് സെഷനുകളും നിർത്താം. വ്യക്തമായ പാതയിൽ ഇത് അദൃശ്യമാണ്. നഷ്ടമുള്ള പാതയിൽ ചികിത്സ ലക്ഷണത്തേക്കാൾ മോശമാണ്.
ബദൽ കണക്റ്റിവിറ്റി ഇല്ലാത്തതാണെങ്കിൽ ഈ കൈമാറ്റം സ്വീകാര്യമാണ്, അത് സാധാരണമായി സ്വീകരിക്കുന്നതിന് പകരം ഉടമയുള്ള ഒരു അപവാദമായി രേഖപ്പെടുത്തണം.
ട്രാൻസ്പോർട്ട്, പോർട്ട്, ഒരു മാതൃകാ ക്വറി, അളന്ന ഫലം, തീയതി എന്നിവ രേഖപ്പെടുത്തുക. ആ രേഖ ഇല്ലാതെ അടുത്ത എൻജിനിയർ പരീക്ഷണം ആവർത്തിക്കും, അപവാദം നിശ്ശബ്ദമായി ആർക്കിടെക്ചറായി മാറും.
തീരുമാനം പുനഃപരിശോധിക്കാവുന്നതായി നിലനിർത്തുക
പാതയുടെ രോഗനിർണ്ണയം വേഗം പഴകുന്നു. ഇടനില പെട്ടി മാറ്റുന്നു, ബ്ലേഡ് ക്രമീകരണം മാറുന്നു, ലിങ്ക് അപ്ഗ്രേഡ് ചെയ്യുന്നു, 443-ലെ TCP-യുടെ കാരണം അപ്രത്യക്ഷമാകുമ്പോൾ ക്രമീകരണം നിലനിൽക്കുന്നു. അപവാദത്തിന് പുനഃപരിശോധന തീയതി ഇടുക, UDP-യിലേക്ക് മടങ്ങാൻ അനുവദിക്കുന്ന വ്യവസ്ഥ പേരെടുത്ത് പറയുക.
ചെറിയ ക്വറിയോടും വലിയ ഫല ഗണത്തോടും രണ്ട് ട്രാൻസ്പോർട്ടുകളും പരീക്ഷിക്കുക. പുനഃക്രമീകരണം വലിപ്പാധിഷ്ഠിത തടസ്സങ്ങളായി പ്രത്യക്ഷപ്പെടുന്നു, ശ്രോതാവിന്റെ തകരാർ രണ്ട് വലിപ്പങ്ങളെയും തുല്യമായി നിർത്തുന്നു.