En ping-vakt kan ikke skille en ødelagt tunnel fra en frisk

Tre forhold avgjør om en vakt hjelper eller skader: hva sonden klarer å skille, hvor mange feil på rad som rettferdiggjør et inngrep, og om inngrepet er en ny tilkobling eller et bytte. En cron-linje som pinger en offentlig adresse gir ikke gode svar på noen av delene. Den kobler opp tunneler som er friske på nytt og lar ødelagte tunneler ligge, og den gjør begge deler uten å føre protokoll. Oppsettet som er verdt å beholde, gjør disse tre valgene bevisste.

Sonden er den delen som bestemmer alt det andre.

Hva en ping ut mot internett egentlig beviser

Ping mot en offentlig navnetjener viser at den lokale nettveien er i live. Det beviser ikke at tunnelen frakter trafikk, og med full tunnel går selve pinget gjennom tunnelen, så et friskt svar og en ødelagt tunnel kan finnes samtidig mens klienten ennå videresender pakker. Sender oppsettet navneoppslag gjennom tunnelen, blir en DNS-feil lest som en død forbindelse og starter en ny tilkobling som ikke kan rette opp noe.

Ingen av feilens to retninger vises i utgangskoden. En vakt bygget på dette signalet er et myntkast med cron-plan.

Undersøk noe som bor bak tunnelen

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

Undersøk innenfra, den billigste sjekken først. Finnes grensesnittet, er tunnelen oppe; et ruteoppslag mot en kjent intern adresse viser at trafikk ville gå inn dit; en TCP-sjekk mot en vert på den andre siden viser at noe faktisk svarer. Bare echo-forespørsler lurer deg: mange interne verter svarer gjerne på TCP, men slipper ICMP, så en vakt basert på ping kobler stadig opp igjen en tunnel som aldri sluttet å virke.

Hold sonden tidsbegrenset og gi den en egen utgangsverdi. En sonde som henger i tretti sekunder gjør en vakt om til en utfallsdetektor med innebygd forsinkelse.

Velg mellom én linje og en løkke

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

En cron-oppføring er én linje uten hukommelse, og passer på en bærbar maskin der en ekstra tilkobling ikke koster noe. En overvåket løkke holder orden på antall feil og griper først inn etter flere bom, noe som hindrer en ustabil linje i å utløse en flom av tilkoblinger. Uansett bør den kjøres under en overvåker, slik at den overlever et krasj og skriver til loggen. Velg ut fra om en unødvendig tilkobling betyr noe, ikke ut fra hvilken utgave som er kortest.

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

Løkka teller feil på rad i stedet for en andel over et tidsvindu. Et vindu krever klokke og hukommelse for målinger, og de fleste feilene i hjemmelagde vakter ligger i nettopp denne aritmetikken.

Serverbytte er en annen beslutning

Å bytte server er ikke det samme som å koble opp på nytt. Riv ned den gamle forbindelsen først, for en klient som starter mens den første ennå holder adressen, vil kollidere. Tell feil på rad før byttet, sett et tak på forsøkene, og sjekk på nytt når den nye forbindelsen er oppe, i stedet for å stole på utgangsverdien fra connect-kommandoen. En gal konfigurasjon skal ikke gå på rundgang gjennom hver server i en løkke.

Ikke sjekk VPN-serverens egen offentlige adresse fra innsiden av en full tunnel. Den sjekken avhenger av det den tester, og den melder suksess mens veien den skulle bekrefte er borte.

Skriv ned hvilken sonde som kjørte, hva den ga tilbake og hvilket inngrep som fulgte. Den protokollen gjør en mystisk ny tilkobling om til en hendelse som kan diagnosticeres.