പിംഗ് കാവൽക്കാരന് തകർന്ന ടണൽ ആരോഗ്യമുള്ളതിൽ നിന്ന് വേർതിരിച്ചറിയാനാവില്ല

മൂന്ന് വ്യവസ്ഥകളാണ് കാവൽക്കാരൻ സഹായിക്കുന്നോ ഉപദ്രവിക്കുന്നോ എന്ന് തീരുമാനിക്കുന്നത്: പരിശോധനയ്ക്ക് എന്ത് വേർതിരിച്ചറിയാനാവും, എത്ര തുടർച്ചയായ പരാജയങ്ങൾ നടപടിയെ ന്യായീകരിക്കും, നടപടി വീണ്ടും ബന്ധിപ്പിക്കലാണോ മാറ്റമാണോ. പൊതു വിലാസത്തിലേക്ക് പിംഗ് ചെയ്യുന്ന cron വരി ഇവയൊന്നിനും നല്ല ഉത്തരം നൽകുന്നില്ല. അത് ആരോഗ്യമുള്ള ടണലുകൾ വീണ്ടും ബന്ധിപ്പിക്കുന്നു, തകർന്നവ ഉള്ളതുപോലെ വിടുന്നു, രണ്ടും ഒരു രേഖയുമില്ലാതെ ചെയ്യുന്നു. നിലനിർത്താൻ യോഗ്യമായ രൂപകൽപ്പന ഈ മൂന്ന് തിരഞ്ഞെടുപ്പുകൾ വ്യക്തമാക്കുന്നു.

ബാക്കിയെല്ലാം തീരുമാനിക്കുന്ന ഭാഗമാണ് പരിശോധന.

ഇന്റർനെറ്റിലേക്കുള്ള പിംഗ് യഥാർഥത്തിൽ എന്ത് തെളിയിക്കുന്നു

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

പിശകിന്റെ രണ്ട് ദിശകളിൽ ഒന്നും എക്സിറ്റ് കോഡിൽ കാണുന്നില്ല. ആ സിഗ്നലിൽ പണിത കാവൽക്കാരൻ cron ഷെഡ്യൂളുള്ള ഒരു നാണയമെറിയലാണ്.

ടണലിന് പിന്നിൽ ജീവിക്കുന്ന എന്തെങ്കിലും പരിശോധിക്കുക

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

ഉള്ളിൽ നിന്ന് പരിശോധിക്കുക, ഏറ്റവും വിലകുറഞ്ഞ പരിശോധന ആദ്യം. ഇന്റർഫേസ് ഉണ്ടോ എന്നത് ടണൽ മുകളിലാണെന്ന് പറയുന്നു; അറിയപ്പെടുന്ന ആന്തരിക വിലാസത്തിലേക്കുള്ള റൂട്ട് തിരയൽ ട്രാഫിക് അങ്ങോട്ട് കയറുമെന്ന് പറയുന്നു; മറുവശത്തെ ഹോസ്റ്റിലേക്കുള്ള TCP പരിശോധന എന്തോ ശരിക്കും മറുപടി നൽകുന്നുവെന്ന് പറയുന്നു. echo അഭ്യർഥനകൾ മാത്രം വഴിതെറ്റിക്കുന്നു: പല ആന്തരിക ഹോസ്റ്റുകളും TCP-യ്ക്ക് സന്തോഷത്തോടെ മറുപടി നൽകുമെങ്കിലും ICMP ഉപേക്ഷിക്കുന്നു, അതിനാൽ പിംഗിൽ പണിത കാവൽക്കാരൻ ഒരിക്കലും പ്രവർത്തനം നിർത്താത്ത ടണൽ വീണ്ടും വീണ്ടും ബന്ധിപ്പിക്കുന്നു.

പരിശോധന സമയപരിധിയിൽ നിർത്തി അതിന് വേറിട്ട എക്സിറ്റ് അവസ്ഥ നൽകുക. മുപ്പത് സെക്കൻഡ് തൂങ്ങിക്കിടക്കുന്ന പരിശോധന കാവൽക്കാരനെ അന്തർനിർമിത കാലതാമസമുള്ള തടസ്സം കണ്ടെത്തുന്ന ഉപകരണമാക്കി മാറ്റുന്നു.

ഒരു വരിയും ഒരു ലൂപ്പും തമ്മിൽ തിരഞ്ഞെടുക്കുക

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

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

failures=0
while sleep 30; do
  if nc -z -w5 10.100.20.10 443; then failures=0
  else failures=$((failures+1)); fi
  if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi
done

ആ ലൂപ്പ് ഒരു വിൻഡോയിലെ അനുപാതത്തിന് പകരം തുടർച്ചയായ പരാജയങ്ങൾ എണ്ണുന്നു. വിൻഡോയ്ക്ക് ഒരു ഘടികാരവും സാമ്പിളുകളുടെ ഓർമയും വേണം, കൈകൊണ്ട് എഴുതിയ കാവൽക്കാരുടെ മിക്ക ബഗുകളും ആ കണക്കിൽ തന്നെ ജീവിക്കുന്നു.

സർവർ മാറ്റം മറ്റൊരു തീരുമാനമാണ്

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

പൂർണ ടണലിനുള്ളിൽ നിന്ന് VPN സർവറിന്റെ സ്വന്തം പൊതു വിലാസം പരിശോധിക്കരുത്. ആ പരിശോധന അത് പരീക്ഷിക്കുന്ന കാര്യത്തെ ആശ്രയിക്കുന്നു, സാധൂകരിക്കേണ്ട പാത ഇല്ലാതായാലും വിജയം റിപ്പോർട്ട് ചെയ്യുന്നു.

ഏത് പരിശോധന നടന്നു, എന്ത് തിരികെ നൽകി, ഏത് നടപടി പിന്നാലെ വന്നു എന്ന് രേഖപ്പെടുത്തുക. ആ രേഖ ദുരൂഹമായ വീണ്ടും ബന്ധിപ്പിക്കലിനെ രോഗനിർണയം ചെയ്യാവുന്ന സംഭവമാക്കി മാറ്റുന്നു.