Ping čuvar ne razlikuje pokvaren tunel od zdravog

Tri uslova odlučuju da li čuvar pomaže ili šteti: šta proba može razlikovati, koliko uzastopnih neuspjeha opravdava mjeru i da li je mjera ponovno povezivanje ili prebacivanje. Cron red koji pinguje javnu adresu ne odgovara dobro ni na jedan od njih. On ponovo povezuje tunele koji su u redu i ostavlja pokvarene tunele kakvi jesu, i oboje radi bez ikakvog zapisa. Rješenje koje vrijedi zadržati čini ta tri izbora jasnim.

Proba je dio koji odlučuje o svemu ostalom.

Šta ping prema internetu zaista dokazuje

Ping prema javnom razrješivaču pokazuje da je lokalni internetski put živ. To ne dokazuje da tunel prenosi saobraćaj, a na profilu punog tunela sam ping ide kroz tunel, pa ispravan odgovor i pokvaren tunel mogu postojati istovremeno 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. Čuvar 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, ali odbacuju ICMP, pa čuvar 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 čuvara 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 na kojem dodatno povezivanje ništa ne košta. Nadzirana 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 čuvarima ž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.