Ping-сторож не відрізняє зламаний тунель від справного

Пінг в інтернет доводить менше, ніж здається. Перевіряйте тунель зсередини, рахуйте збої перед дією та вважайте перемикання сервера окремим рішенням.

Три умови вирішують, чи сторож допомагає, чи шкодить: що здатна розрізнити перевірка, скільки послідовних збоїв виправдовують дію і чи є дія перепідключенням або перемиканням. Рядок 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-сервера зсередини повного тунелю. Ця перевірка залежить від того, що вона тестує, і повідомляє про успіх, коли шляху, який вона мала підтвердити, вже немає.

Запишіть, яка перевірка виконувалася, що вона повернула і яка дія сталася далі. Цей запис перетворює загадкове перепідключення на подію, яку можна діагностувати.

Схожі статті