ഫെയിൽഓവർ പരിശോധന: സ്ഥാപിത TCP സ്ട്രീം അതിജീവിക്കുമോ?

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

ഒരു വിജയം പോലെ തോന്നുന്ന രണ്ട് ഫലങ്ങൾ

10.90.0.42-ൽ ഉള്ള ഒരു ക്ലയന്റിന് 198.51.100.20:443-ലേക്ക് കണക്ഷൻ ഉണ്ടെന്ന് സങ്കൽപ്പിക്കുക. പ്രാഥമിക എക്സിറ്റ് അതിനെ ഒരു പൊതു വിലാസത്തിലേക്കും പോർട്ടിലേക്കും മാറ്റുന്നു, ബാക്കപ്പ് എക്സിറ്റ് മറ്റൊന്നിലേക്ക്. ക്ലയന്റിന്റെ ആന്തരിക വിലാസം ഒരിക്കലും മാറുന്നില്ല, അതുകൊണ്ടാണ് കണക്ഷൻ അതിജീവിക്കുമെന്ന് ആളുകൾ പ്രതീക്ഷിക്കുന്നത്.

സെർവർ ആന്തരിക വിലാസം കാണുന്നില്ല. അത് പരിഭാഷപ്പെടുത്തിയ അന്ത്യബിന്ദു കാണുന്നു, ആ ബിന്ദു സ്വിച്ചിന് ശേഷം വ്യത്യസ്തമാണ്.

അതിനാൽ പഴയ സ്ട്രീം സമയപരിധി കഴിഞ്ഞ് അവസാനിക്കുന്നു, അതേ സേവനത്തിലേക്കുള്ള പുതിയ കണക്ഷൻ ഉടൻ പ്രവർത്തിക്കുന്നു. രണ്ട് നിരീക്ഷണങ്ങളും ഒരേ സമയം ശരിയാണ്.

എക്സിറ്റ് മാറുമ്പോൾ സെർവർ കാണുന്നത്

TCP കണക്ഷൻ അതിന്റെ നാലംശത്താൽ തിരിച്ചറിയപ്പെടുന്നു, ഉറവിട വിലാസമോ പോർട്ടോ മാറ്റുന്നത് സ്വീകരിക്കുന്ന ഹോസ്റ്റിന് വേറെ കണക്ഷൻ സൃഷ്ടിക്കുന്നു. സെർവറിന് അറിയാത്ത കണക്ഷനിൽ പുതിയ ഉറവിടത്തിൽ നിന്ന് വരുന്ന പാക്കറ്റുകൾ വലിച്ചെറിയുകയോ റീസെറ്റ് ഉപയോഗിച്ച് മറുപടി നൽകുകയോ ചെയ്യുന്നു. VPN ക്ലയന്റിന്റെ വിലാസത്തിൽ ആ മാറ്റത്തിലുടനീളം ബന്ധം നിലനിർത്തുന്ന ഒന്നുമില്ല.

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

ആർക്കെങ്കിലും തുടർച്ച വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് ജോടി ശരിക്കും അവസ്ഥ സൂക്ഷിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. താഴെയുള്ള കമാൻഡുകൾ ഇരു വശങ്ങളിലെയും നിലവിലെ അവസ്ഥ കാണിക്കുന്നു.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

ഒരേ പൊതു വിലാസം എന്തുകൊണ്ട് മതിയാകുന്നില്ല

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

RFC 3022 വിലാസ പരിഭാഷ വിവരിക്കുന്നു, പരിഭാഷ ചെയ്യുന്ന ഉപകരണങ്ങൾക്കിടയിലെ അവസ്ഥ കൈമാറ്റത്തെ ബാക്കപ്പ് രൂപകൽപ്പനയുടെ ഭാഗമായി കണക്കാക്കുന്നു. ഒഴുകുന്ന വിലാസമോ പകർത്തിയ പ്രൊഫൈലോ കോൺഫിഗറേഷൻ നീക്കുന്നു, അവസ്ഥ നീക്കുന്നില്ല.

അതുകൊണ്ടാണ് ബാക്കപ്പിലൂടെ മാത്രം പിംഗ് ചെയ്യുന്ന പരിശോധന വളരെ കുറച്ച് മാത്രം തെളിയിക്കുന്നത്. പിംഗിന് നഷ്ടപ്പെടാൻ കണക്ഷൻ അവസ്ഥയില്ല.

ആവശ്യകത എത്ര ശക്തമാണെന്ന് തീരുമാനിക്കുക

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

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

പ്രാഥമിക പാത മടങ്ങിവരുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് വ്യക്തമായി പറയുക, കാരണം യാന്ത്രിക ഫെയിൽബാക്ക് ബാക്കപ്പിൽ ഇപ്പോൾ വീണ്ടെടുത്ത കണക്ഷൻ മുറിച്ചേക്കാം. ആ കേസ് പരിശോധനാ പ്ലാനിലാണ്, അടിക്കുറിപ്പിലല്ല.

പഴയ സ്ട്രീമും പുതിയ അഭ്യർത്ഥനയും പരിശോധിക്കുക

പ്രാഥമിക പാതയിലൂടെ ഹാനികരമല്ലാത്ത ദീർഘമായ കൈമാറ്റം ആരംഭിക്കുക, തുടർന്ന് അതേ സേവനത്തിലേക്ക് വേറെ പുതിയ അഭ്യർത്ഥന. ആപ്ലിക്കേഷൻ സന്ദർഭം, നിരീക്ഷിച്ച എക്സിറ്റ് വിലാസം, സമയം എന്നിവ രേഖപ്പെടുത്തുക. അനുവദിച്ച രീതിയിൽ പ്രാഥമിക പാത തകർത്ത്, ബാക്കപ്പിലൂടെ പുതിയ അഭ്യർത്ഥന അയക്കുമ്പോൾ യഥാർത്ഥ കൈമാറ്റം നിരീക്ഷിച്ചുകൊണ്ടിരിക്കുക.

മൂന്ന് മൂല്യങ്ങൾ റിപ്പോർട്ട് ചെയ്യുക: പഴയ സ്ട്രീം തുടർന്നോ, റീസെറ്റ് ചെയ്തോ, സമയപരിധി കഴിഞ്ഞോ; പുതിയ പ്രവർത്തനം ആദ്യമായി എപ്പോൾ പ്രവർത്തിച്ചു; ഫെയിൽബാക്ക് എന്തെങ്കിലും മുറിച്ചോ. ആ മൂന്ന് വരികളാണ് സ്വീകാര്യതാ രേഖ.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

വർക്ക്ലോഡ് ഡാറ്റ എഴുതുന്നുണ്ടെങ്കിൽ, സമയപരിധിക്ക് ശേഷം അനിശ്ചിതമായ പ്രവർത്തനം കണ്ണടച്ച് ആവർത്തിക്കരുത്. മറുപടി നഷ്ടപ്പെടുന്നതിന് മുമ്പ് എഴുത്ത് എത്തിയിരിക്കാം. ആപ്ലിക്കേഷനോട് ഫലം ചോദിക്കുക, അല്ലെങ്കിൽ പ്രവർത്തനം ഐഡംപൊട്ടന്റ് ആയിടത്ത് മാത്രം വീണ്ടും ശ്രമിക്കുക. തുടർന്ന് സ്വീകാര്യതാ പ്രസ്താവന മൂന്ന് ഭാഗങ്ങളായി എഴുതുക: പുതിയ പ്രവർത്തനങ്ങൾ എക്സിറ്റ് നയപ്രകാരം വീണ്ടെടുക്കുന്നു, നിലവിലുള്ള സ്ട്രീമുകൾക്ക് രേഖപ്പെടുത്തിയ തടസ്സ സ്വഭാവമുണ്ട്, ആപ്ലിക്കേഷൻ സുരക്ഷിതമായി തുടരുന്നു. ആ പ്രസ്താവന പരിശോധിക്കാവുന്നതാണ്, രൂപകൽപ്പന എന്ത് വാഗ്ദാനം ചെയ്യുന്നില്ല എന്നതിൽ അത് സത്യസന്ധമാണ്.