En ping-vakt skiljer inte en trasig tunnel från en frisk

Tre villkor avgör om en vakt hjälper eller skadar: vad sonden kan skilja på, hur många fel i rad som motiverar en åtgärd och om åtgärden är en återanslutning eller ett byte. En cron-rad som pingar en publik adress svarar inte bra på något av dem. Den återansluter tunnlar som är i ordning och lämnar tunnlar som är trasiga som de är, och den gör båda utan någon registrering. Den design som är värd att behålla gör de tre valen tydliga.

Sonden är den del som avgör allt annat.

Vad en ping mot internet faktiskt bevisar

Att pinga en publik resolver visar att den lokala internetvägen lever. Det bevisar inte att tunneln bär trafik, och på en profil med full tunnel går själva pinget genom tunneln, så ett friskt svar och en trasig tunnel kan finnas samtidigt medan klienten fortfarande vidarebefordrar paket. Om profilen skickar namnslagningar genom tunneln läses ett DNS-fel som en död förbindelse och startar en återanslutning som inte kan rätta något.

Ingen av felets två riktningar syns i utgångskoden. En vakt byggd på den signalen är ett myntkast med ett cron-schema.

Undersök något som lever bakom tunneln

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

Undersök inifrån, den billigaste kontrollen först. Om gränssnittet finns säger det att tunneln är uppe; en ruteuppslagning mot en känd intern adress säger att trafik skulle gå in i den; en TCP-sond mot en värd på andra sidan säger att något faktiskt svarar. Bara echo-förfrågningar vilseleder: många interna värdar svarar gärna på TCP men släpper ICMP, så en vakt byggd på ping återansluter ständigt en tunnel som aldrig slutade fungera.

Håll sonden tidsbegränsad och ge den en egen utgångsstatus. En sond som hänger i trettio sekunder förvandlar en vakt till en avbrottsdetektor med inbyggd fördröjning.

Välj mellan en rad och en slinga

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

En cron-post är en enda rad utan minne, vilket passar en bärbar dator där en extra återanslutning inte kostar något. En övervakad slinga håller en räknare och agerar först efter flera missar, vilket hindrar en ostadig länk från att utlösa en storm av återanslutningar. Oavsett vilket bör du köra den under en supervisor så att den överlever en krasch och skriver till journalen. Välj utifrån om en falsk återanslutning spelar roll, inte utifrån vilken version som är kortast.

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 slingan räknar fel i rad i stället för en andel över ett fönster. Ett fönster kräver en klocka och ett minne av prover, och de flesta fel i handskrivna vakter bor i den aritmetiken.

Bytet av server är ett annat beslut

Att byta server skiljer sig från att återansluta. Riv först ner den gamla förbindelsen, eftersom en andra klient som startar medan den första fortfarande håller adressen kommer att kollidera. Räkna fel i rad före bytet, begränsa försöken och undersök igen när den nya förbindelsen är uppe i stället för att lita på utgångsstatusen från connect-kommandot. En felaktig konfiguration bör inte rotera genom varje server i en slinga.

Undersök inte VPN-serverns egen publika adress inifrån en full tunnel. Den kontrollen beror på det den testar och rapporterar framgång medan vägen den skulle bekräfta är borta.

Anteckna vilken sond som körde, vad den returnerade och vilken åtgärd som följde. Den anteckningen förvandlar en mystisk återanslutning till en händelse som går att diagnostisera.