Три услова одлучују да ли чувар помаже или штети: шта провера може да разликује, колико узастопних неуспеха оправдава деловање и да ли је деловање поновно повезивање или пребацивање. Ред cron-а који пингује јавну адресу не одговара добро ни на једно од тога. Он поново повезује тунеле који су у реду и оставља покварене тунеле какви јесу, и оба ради без икаквог записа. Решење које вреди задржати чини та три избора јасним.

Провера је део који одлучује о свему осталом.

Шта ping ка интернету заиста доказује

Пинг ка јавном resolver-у показује да је локални интернет пут жив. То не доказује да тунел преноси саобраћај, а на профилу пуног тунела сам ping иде кроз тунел, па исправан одговор и покварен тунел могу постојати истовремено док клијент још прослеђује пакете. Ако профил шаље претраге имена кроз тунел, DNS неуспех се чита као мртва веза и покреће поновно повезивање које не може ништа да поправи.

Ниједан од два смера грешке не појављује се у излазном коду. Чувар изграђен на том сигналу је бацање новчића са cron распоредом.

Проверите нешто што живи иза тунела

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

Проверавајте изнутра, најјефтинија провера прва. Постоји ли интерфејс говори да је тунел подигнут; тражење руте до познате унутрашње адресе говори да би саобраћај ушао у њу; TCP провера ка хосту са друге стране говори да нешто заиста одговара. Сами echo захтеви обмањују: многи унутрашњи host-ови радо одговарају на TCP, али одбацују ICMP, па чувар изграђен на ping-у стално поново повезује тунел који никада није престао да ради.

Држите проверу временски ограниченом и дајте јој посебан излазни статус. Провера која виси тридесет секунди претвара чувара у детектор прекида са уграђеним кашњењем.

Изаберите између једног реда и петље

* * * * * 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 сервера из унутрашњости пуног тунела. Та провера зависи од ствари коју тестира и пријављује успех док је пут који је требало да потврди већ нестао.

Запишите која је провера радила, шта је вратила и која је радња уследила. Тај запис претвара тајанствено поновно повезивање у догађај који се може дијагностиковати.

Повезани чланци