Ping-gardisto ne distingas rompitan tunelon de sana

Tri kondiĉoj decidas ĉu gardisto helpas aŭ malhelpas: kion la kontrolo povas distingi, kiom da sinsekvaj malsukcesoj pravigas agon, kaj ĉu la ago estas rekonekto aŭ ŝanĝo. Cron-linio, kiu pingsa publikan adreson, bone respondas al neniu el ili. Ĝi rekonektas tunelojn, kiuj estas en ordo, kaj lasas tunelojn, kiuj estas rompitaj, kaj faras ambaŭ sen registro. La dezajno inda je konservo faras tiujn tri elektojn eksplicitaj.

La kontrolo estas la parto, kiu decidas ĉion alian.

Kion ping al la interreto efektive pruvas

Pingi publikan solvilon montras, ke la loka interreta vojo vivas. Ĝi ne pruvas, ke la tunelo portas trafikon, kaj en profilo de plena tunelo la ping mem vojaĝas tra la tunelo, do sana respondo kaj rompita tunelo povas ekzisti samtempe, dum la kliento ankoraŭ plusendas pakaĵojn. Se la profilo sendas nomserĉojn tra la tunelo, DNS-malsukceso legiĝas kiel morta ligo kaj komencas rekonekton, kiu povas ripari nenion.

Neniu el la du direktoj de la eraro aperas en la elirkodo. Gardisto konstruita sur tiu signalo estas monĵeto kun cron-horaro.

Kontrolu ion, kio vivas malantaŭ la tunelo

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

Kontrolu de interne, la plej malmultekosta kontrolo unue. Ĉu la interfaco ekzistas diras, ke la tunelo staras; vojserĉo al konata interna adreso diras, ke trafiko enirus ĝin; TCP-kontrolo al gastiganto sur la alia flanko diras, ke io efektive respondas. Nur echo-petoj trompas: multaj internaj gastigantoj volonte respondas al TCP sed forĵetas ICMP, do gardisto bazita sur ping daŭre rekonektas tunelon, kiu neniam ĉesis funkcii.

Tenu la kontrolon limigita en tempo kaj donu al ĝi apartan elirstaton. Kontrolo, kiu pendas tridek sekundojn, transformas gardiston en eltrovilon de interrompoj kun enkonstruita prokrasto.

Elektu inter unu linio kaj buklo

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

Cron-enskribo estas unu linio sen memoro, kio taŭgas por tekkomputilo, kie plia rekonekto kostas nenion. Superrigardata buklo tenas nombrilon kaj agas nur post pluraj maltrafaĵoj, kio malhelpas malstabilan ligon kaŭzi ŝtormon de rekonektoj. Ĉiukaze, rulu ĝin sub superrigardo, por ke ĝi postvivu kraŝon kaj skribu al la ĵurnalo. Elektu laŭ tio, ĉu senbezona rekonekto gravas, ne laŭ tio, kiu versio estas pli mallonga.

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

Tiu buklo kalkulas sinsekvajn malsukcesojn anstataŭ frakcion super fenestro. Fenestro bezonas horloĝon kaj memoron de specimenoj, kaj la plej multaj cimoj en permane konstruitaj gardistoj vivas en tiu aritmetiko.

Ŝanĝo al alia servilo estas alia decido

Ŝanĝi servilojn malsamas de rekonekti. Unue disŝiru la malnovan ligon, ĉar dua kliento, kiu ekfunkcias dum la unua ankoraŭ tenas la adreson, kolizios. Kalkulu sinsekvajn malsukcesojn antaŭ la ŝanĝo, limigu la provojn, kaj kontrolu denove, kiam la nova ligo staras, anstataŭ fidi la elirkodon de la komando connect. Malĝusta agordo ne devus rotacii tra ĉiu servilo en buklo.

Ne kontrolu la propran publikan adreson de la VPN-servilo de interne de plena tunelo. Tiu kontrolo dependas de la afero, kiun ĝi testas, kaj raportas sukceson dum la vojo, kiun ĝi devis validigi, jam mankas.

Registru, kiu kontrolo kuris, kion ĝi redonis kaj kiu ago sekvis. Tiu registro transformas misteran rekonekton en diagnozeblan eventon.