Пинг наблюдател не различава счупен тунел от здрав

Пингът към интернет доказва по-малко, отколкото изглежда. Проверявайте тунела отвътре, броете неуспехите преди действие и третирайте превключването като отделно решение.

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

Запишете коя проверка е вървяла, какво е върнала и какво действие е последвало. Този запис превръща мистериозното пресвързване в събитие, което може да се диагностицира.

Подобни статии