En ping-vekter skiller ikke en brutt tunnel fra en sunn

En ping mot internett beviser mindre enn det ser ut som. Sjekk tunnelen innenfra, tell feil før du handler, og behandle bytte av server som en egen avgjørelse.

Tre forhold avgjør om en vekter hjelper eller skader: hva sonden kan skille, hvor mange påfølgende feil som rettferdiggjør handling, og om handlingen er en gjenoppkobling eller et bytte. En cron-linje som pinger en offentlig adresse svarer ikke godt på noen av dem. Den kobler til tunneler som er i orden på nytt og lar tunneler som er brutt være, og den gjør begge deler uten en registrering. Designet som er verdt å beholde gjør de tre valgene tydelige.

Sonden er den delen som avgjør alt annet.

Hva en ping mot internett faktisk beviser

Å pinge en offentlig resolver viser at den lokale internettruten er levende. Det beviser ikke at tunnelen bærer trafikk, og på en profil med full tunnel går selve pinget gjennom tunnelen, så et sunt svar og en brutt tunnel kan finnes samtidig mens klienten fortsatt videresender pakker. Hvis profilen sender navneoppslag gjennom tunnelen, leses en DNS-feil som en død forbindelse og starter en gjenoppkobling som ikke kan rette noe.

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

Sjekk noe som lever bak tunnelen

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

Sjekk innenfra, den billigste kontrollen først. Om grensesnittet finnes, sier at tunnelen er oppe; et ruteoppslag mot en kjent intern adresse sier at trafikk ville gå inn i den; en TCP-sonde mot en vert på den andre siden sier at noe faktisk svarer. Bare echo-forespørsler villeder: mange interne verter svarer gjerne på TCP men slipper ICMP, så en vekter bygget på ping kobler stadig på nytt en tunnel som aldri sluttet å virke.

Hold sonden tidsbegrenset og gi den en egen utgangsstatus. En sonde som henger i tretti sekunder gjør en vekter 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, noe som passer en bærbar PC der en ekstra gjenoppkobling ikke koster noe. En overvåket løkke holder en teller og handler først etter flere feil, noe som hindrer en ustabil linje i å utløse en storm av gjenoppkoblinger. Uansett bør du kjøre den under en supervisor så den overlever en krasj og skriver til journalen. Velg ut fra om en falsk gjenoppkobling betyr noe, ikke ut fra hvilken versjon 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

Den løkken teller påfølgende feil i stedet for en brøkdel over et vindu. Et vindu krever en klokke og en hukommelse av prøver, og de fleste feilene i håndskrevne vektere bor i den aritmetikken.

Bytte av server er en annen avgjørelse

Å bytte server er noe annet enn å koble på nytt. Riv ned den gamle forbindelsen først, fordi en annen klient som starter mens den første fortsatt holder adressen, vil kollidere. Tell påfølgende feil før byttet, begrens forsøkene, og sjekk på nytt når den nye forbindelsen er oppe i stedet for å stole på utgangsstatusen til connect-kommandoen. En feil konfigurasjon bør ikke rotere gjennom hver server i en løkke.

Ikke sjekk VPN-serverens egen offentlige adresse innenfra en full tunnel. Den kontrollen avhenger av det den tester, og den rapporterer suksess mens veien den skulle bekrefte er borte.

Registrer hvilken sonde som kjørte, hva den returnerte og hvilken handling som fulgte. Den registreringen gjør en mystisk gjenoppkobling til en hendelse som kan diagnostiseres.

Relaterte artikler