یک نگهبان پینگ نمی‌تواند تونل خراب را از تونل سالم تشخیص دهد

سه شرط تعیین می‌کند که یک نگهبان کمک می‌کند یا آسیب می‌زند: اینکه بررسی چه چیزهایی را می‌تواند از هم تشخیص دهد، چند شکست پیاپی توجیه اقدام می‌کند، و اینکه اقدام یک اتصال دوباره است یا تغییر سرور. یک خط cron که به یک نشانی عمومی پینگ می‌زند به هیچ‌یک از این‌ها خوب پاسخ نمی‌دهد. تونل‌هایی را که سالماند دوباره وصل می‌کند و تونل‌هایی را که خراب‌اند رها می‌کند، و هر دو را بدون هیچ ثبت و ضبطی انجام می‌دهد. طرحی که ارزش نگه داشتن دارد این سه انتخاب را صریح می‌کند.

بررسی همان بخشی است که همه چیز دیگر را تعیین می‌کند.

پینگ به اینترنت واقعاً چه چیزی را ثابت می‌کند

پینگ به یک resolver عمومی نشان می‌دهد که مسیر محلی اینترنت زنده است. ثابت نمی‌کند که تونل ترافیک حمل می‌کند، و در نمایه تونل کامل خود پینگ از داخل تونل می‌گذرد، پس پاسخ سالم و تونل خراب می‌توانند همزمان وجود داشته باشند در حالی که کلاینت هنوز بسته‌ها را هدایت می‌کند. اگر نمایه جستجوی نام‌ها را از داخل تونل بفرستد، شکست 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 را از داخل یک تونل کامل بررسی نکنید. آن بررسی به همان چیزی وابسته است که آزمایشش می‌کند، و موفقیت گزارش می‌کند در حالی که مسیری که باید تأییدش می‌کرد دیگر نیست.

ثبت کنید کدام بررسی اجرا شد، چه بازگرداند و چه اقدامی در پی آمد. آن ثبت یک اتصال دوباره مرموز را به رویدادی قابل تشخیص تبدیل می‌کند.