Ping watchdog ne razlikuje pokvaren tunel od ispravnog

Tri uslova odlučuju da li watchdog pomaže ili šteti: šta proba može razlikovati, koliko uzastopnih neuspjeha opravdava djelovanje i da li je djelovanje ponovno povezivanje ili prebacivanje. Cron red koji pinga javnu adresu ne odgovara dobro ni na jedno od njih. On ponovo povezuje tunel koji je ispravan i ostavlja tunel koji je pokvaren, i oboje radi bez zapisa. Dizajn koji vrijedi zadržati čini te tri izbore eksplicitnim.

Proba je dio koji odlučuje o svemu ostalom.

Šta ping prema internetu zapravo dokazuje

Ping prema javnom resolveru pokazuje da je lokalni internet put živ. To ne dokazuje da tunel prenosi saobraćaj, a na profilu punog tunela sam ping putuje kroz tunel, pa ispravan odgovor i pokvaren tunel mogu postojati zajedno dok klijent još prosljeđuje pakete. Ako profil šalje pretrage imena kroz tunel, DNS neuspjeh se čita kao mrtva veza i pokreće ponovno povezivanje koje ne može ništa popraviti.

Nijedan od dva smjera greške ne pojavljuje se u izlaznom kodu. Watchdog izgrađen na tom signalu je bacanje novčića s cron rasporedom.

Provjerite nešto što živi iza tunela

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

Provjeravajte iznutra, najjeftinija provjera prva. Postoji li interfejs govori da je tunel podignut; traženje rute do poznate interne adrese govori da bi saobraćaj ušao u nju; TCP proba prema hostu s druge strane govori da nešto zaista odgovara. Sami echo zahtjevi obmanjuju: mnogi interni hostovi rado odgovaraju na TCP, a odbacuju ICMP, pa watchdog izgrađen na pingu stalno ponovo povezuje tunel koji nikada nije prestao raditi.

Držite probu vremenski ograničenom i dajte joj poseban izlazni status. Proba koja visi trideset sekundi pretvara watchdog u detektor prekida s ugrađenim kašnjenjem.

Odaberite između jednog reda i petlje

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

Cron unos je jedan red bez memorije, što odgovara laptopu gdje dodatno povezivanje ne košta ništa. Nadgledana petlja drži brojač i djeluje tek nakon nekoliko promašaja, što sprječava nestabilnu vezu da izazove oluju ponovnih povezivanja. U svakom slučaju, pokrenite je pod supervizorom da preživi pad i piše u dnevnik. Birajte prema tome da li lažno povezivanje ima težinu, a ne prema tome koja je verzija kraća.

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

Ta petlja broji uzastopne neuspjehe, a ne udio u prozoru. Prozor traži sat i pamćenje uzoraka, a većina grešaka u ručno pisanim watchdogovima živi upravo u toj aritmetici.

Prebacivanje je druga odluka

Promjena servera razlikuje se od ponovnog povezivanja. Prvo raskinite staru vezu, jer će se drugi klijent koji počne dok prvi još drži adresu sudariti. Brojite uzastopne neuspjehe prije promjene, ograničite pokušaje i provjerite ponovo kada nova veza bude podignuta, umjesto da vjerujete izlaznom statusu connect komande. Pogrešna konfiguracija ne treba da rotira kroz svaki server u petlji.

Ne provjeravajte vlastitu javnu adresu VPN servera iz unutrašnjosti punog tunela. Ta provjera zavisi od stvari koju testira i prijavljuje uspjeh dok je put koji je trebalo potvrditi već nestao.

Zapišite koja je proba radila, šta je vratila i koja je radnja uslijedila. Taj zapis pretvara tajanstveno ponovno povezivanje u događaj koji se može dijagnosticirati.