Un watchdog ping non distingue un tunnel rotto da uno sano

Tre condizioni decidono se un watchdog aiuta o danneggia: cosa riesce a distinguere la sonda, quanti guasti consecutivi giustificano un’azione e se l’azione è una riconnessione o un cambio. Una riga di cron che fa ping a un indirizzo pubblico non risponde bene a nessuna delle tre. Riconnette tunnel che vanno bene e lascia stare tunnel rotti, e fa entrambe le cose senza alcun registro. Il progetto che vale la pena conservare rende esplicite queste tre scelte.

La sonda è la parte che decide tutto il resto.

Che cosa dimostra davvero un ping verso internet

Fare ping a un resolver pubblico mostra che il percorso internet locale è vivo. Non dimostra che il tunnel trasporti traffico, e su un profilo a tunnel completo il ping stesso attraversa il tunnel, quindi una risposta sana e un tunnel rotto possono convivere mentre il client continua a inoltrare pacchetti. Se il profilo manda le ricerche dei nomi attraverso il tunnel, un guasto DNS viene letto come un collegamento morto e avvia una riconnessione che non può sistemare nulla.

Nessuna delle due direzioni dell’errore compare nel codice di uscita. Un watchdog costruito su quel segnale è un lancio di moneta con una pianificazione cron.

Sonda qualcosa che vive dietro il tunnel

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

Sonda dall’interno, il controllo meno costoso per primo. L’esistenza dell’interfaccia dice che il tunnel è su; una ricerca di rotta verso un indirizzo interno noto dice che il traffico vi entrerebbe; una sonda TCP verso un host dall’altra parte dice che qualcosa risponde davvero. Solo le richieste echo ingannano: molti host interni rispondono volentieri al TCP ma scartano ICMP, quindi un watchdog basato sul ping riconnette di continuo un tunnel che non ha mai smesso di funzionare.

Tieni la sonda limitata nel tempo e dalle uno stato di uscita distinto. Una sonda che resta appesa trenta secondi trasforma un watchdog in un rilevatore di interruzioni con un ritardo incorporato.

Scegli tra una riga e un ciclo

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

Una voce di cron è una sola riga senza memoria, il che si adatta a un portatile dove una riconnessione in più non costa nulla. Un ciclo supervisionato tiene un contatore e agisce solo dopo diversi guasti, il che impedisce a un collegamento instabile di scatenare una tempesta di riconnessioni. In ogni caso, eseguilo sotto un supervisore perché sopravviva a un crash e scriva nel journal. Scegli in base al fatto che una riconnessione spuria conti, non in base a quale versione è più corta.

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

Quel ciclo conta guasti consecutivi anziché una frazione su una finestra. Una finestra richiede un orologio e una memoria di campioni, e la maggior parte dei bug nei watchdog scritti a mano vive in quell’aritmetica.

Il cambio di server è un’altra decisione

Cambiare server è diverso dal riconnettere. Strappa prima il vecchio collegamento, perché un secondo client che parte mentre il primo tiene ancora l’indirizzo entrerà in collisione. Conta i guasti consecutivi prima di cambiare, limita i tentativi e sonda di nuovo quando il nuovo collegamento è su, invece di fidarti del codice di uscita del comando connect. Una configurazione sbagliata non dovrebbe ruotare su ogni server in un ciclo.

Non sondare l’indirizzo pubblico del server VPN stesso dall’interno di un tunnel completo. Quel controllo dipende dalla cosa che sta testando e riporta successo mentre il percorso che doveva validare è sparito.

Annota quale sonda è stata eseguita, cosa ha restituito e quale azione è seguita. Quella traccia trasforma una riconnessione misteriosa in un evento diagnosticabile.