Un câine de pază ping nu distinge un tunel rupt de unul sănătos

Trei condiții decid dacă un câine de pază ajută sau dăunează: ce poate distinge sonda, câte eșecuri consecutive justifică o acțiune și dacă acțiunea este o reconectare sau o schimbare. O linie cron care face ping către o adresă publică nu răspunde bine la niciuna dintre ele. Reconectează tuneluri care sunt în regulă și lasă tunelurile rupte așa cum sunt, și face ambele fără nicio înregistrare. Designul care merită păstrat face aceste trei alegeri explicite.

Sonda este partea care decide tot restul.

Ce dovedește de fapt un ping către internet

A face ping către un resolver public arată că drumul local către internet este viu. Nu dovedește că tunelul transportă trafic, iar pe un profil cu tunel complet pingul însuși trece prin tunel, așa că un răspuns sănătos și un tunel rupt pot exista simultan în timp ce clientul încă transmite pachete. Dacă profilul trimite căutările de nume prin tunel, un eșec DNS este citit ca o legătură moartă și pornește o reconectare care nu poate repara nimic.

Niciuna dintre cele două direcții ale erorii nu apare în codul de ieșire. Un câine de pază construit pe acel semnal este o aruncare de monedă cu un program cron.

Sondați ceva ce trăiește dincolo de tunel

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

Sondați din interior, cea mai ieftină verificare mai întâi. Existența interfeței spune că tunelul este sus; o căutare de rută către o adresă internă cunoscută spune că traficul ar intra în ea; o sondă TCP către un host de cealaltă parte spune că ceva răspunde într-adevăr. Doar cererile echo înșală: multe hosturi interne răspund bucuros la TCP dar aruncă ICMP, așa că un câine de pază bazat pe ping reconectează mereu un tunel care nu a încetat niciodată să funcționeze.

Țineți sonda limitată în timp și dați-i un cod de ieșire separat. O sondă care atârnă treizeci de secunde transformă un câine de pază într-un detector de căderi cu întârziere încorporată.

Alegeți între o linie și o buclă

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

O intrare cron este o singură linie fără memorie, ceea ce se potrivește unui laptop unde o reconectare în plus nu costă nimic. O buclă supravegheată ține un contor și acționează abia după mai multe ratări, ceea ce împiedică o legătură instabilă să declanșeze o furtună de reconectări. În orice caz, rulați-o sub un supervizor ca să supraviețuiască unui crash și să scrie în jurnal. Alegeți după dacă o reconectare în plus contează, nu după care versiune este mai scurtă.

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

Bucla aceea numără eșecuri consecutive, nu o fracțiune pe o fereastră. O fereastră are nevoie de un ceas și de o memorie de eșantioane, iar majoritatea erorilor din câinii de pază scriși de mână stau în acea aritmetică.

Schimbarea serverului este altă decizie

Schimbarea serverului diferă de reconectare. Rupeți mai întâi legătura veche, pentru că un al doilea client care pornește cât timp primul ține încă adresa se va ciocni. Numărați eșecurile consecutive înainte de schimbare, limitați încercările și sondați din nou după ce noua legătură este sus, în loc să vă încredeți în codul de ieșire al comenzii connect. O configurație greșită nu ar trebui să rotească prin fiecare server într-o buclă.

Nu sondați adresa publică a serverului VPN însuși din interiorul unui tunel complet. Verificarea aceea depinde de lucrul pe care îl testează și raportează succes în timp ce drumul pe care trebuia să îl valideze a dispărut.

Notați ce sondă a rulat, ce a returnat și ce acțiune a urmat. Acea înregistrare transformă o reconectare misterioasă într-un eveniment diagnosticabil.