Ping nadzornik ne razlikuje pokvaren tunel od ispravnog

Tri uvjeta odlučuju pomaže li nadzornik ili šteti: što proba može razlikovati, koliko uzastopnih neuspjeha opravdava djelovanje i je li djelovanje ponovno povezivanje ili prebacivanje. Cron redak koji pinga javnu adresu ne odgovara dobro ni na jedno od toga. Ponovno povezuje tunele koji su ispravni i ostavlja tunele koji su pokvareni, i oboje radi bez zapisa. Dizajn koji vrijedi zadržati čini ta tri izbora eksplicitnima.

Proba je dio koji odlučuje o svemu ostalom.

Što ping prema internetu zapravo dokazuje

Ping prema javnom razrješivaču pokazuje da je lokalni internetski put živ. To ne dokazuje da tunel prenosi promet, 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 čita se kao mrtva veza i pokreće ponovno povezivanje koje ne može ništa popraviti.

Nijedan od dva smjera pogreške ne pojavljuje se u izlaznom kodu. Nadzornik 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 sučelje govori da je tunel podignut; traženje rute do poznate interne adrese govori da bi promet ušao u nju; TCP proba prema hostu s druge strane govori da nešto doista odgovara. Sami echo zahtjevi zavode: mnogi interni hostovi rado odgovaraju na TCP, ali odbacuju ICMP, pa nadzornik izgrađen na pingu stalno ponovno 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 nadzornika u detektor prekida s ugrađenom odgodom.

Odaberite između jednog retka i petlje

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

Cron unos je jedan redak bez memorije, što odgovara prijenosniku 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 je li lažno povezivanje važno, 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 pogrešaka u ručno pisanim nadzornicima živi upravo u toj aritmetici.

Prebacivanje je druga odluka

Promjena poslužitelja 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 ponovno kad nova veza bude podignuta, umjesto da vjerujete izlaznom statusu naredbe connect. Pogrešna konfiguracija ne bi trebala rotirati kroz svaki poslužitelj u petlji.

Ne provjeravajte vlastitu javnu adresu VPN poslužitelja iz unutrašnjosti punog tunela. Ta provjera ovisi o stvari koju testira i prijavljuje uspjeh dok je put koji je trebalo potvrditi već nestao.

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