Ping stražar ne loči pokvarjenega tunela od zdravega

Trije pogoji odločajo, ali stražar pomaga ali škoduje: kaj zna sonda razlikovati, koliko zaporednih napak upraviči ukrepanje in ali je ukrep ponovna povezava ali preklop. Vrstica cron, ki pinga javni naslov, na nobenega od njih ne odgovori dobro. Ponovno poveže tunele, ki so v redu, in pusti pokvarjene tunele pri miru, oboje pa naredi brez zapisa. Zasnova, ki jo je vredno obdržati, te tri izbire naredi izrecne.

Sonda je del, ki odloča o vsem drugem.

Kaj ping v internet v resnici dokaže

Ping na javni razreševalnik pokaže, da je lokalna internetna pot živa. Ne dokaže, da tunel prenaša promet, in pri profilu polnega tunela sam ping potuje skozi tunel, zato lahko zdrav odgovor in pokvarjen tunel obstajata hkrati, medtem ko odjemalec še vedno posreduje pakete. Če profil pošilja iskanja imen skozi tunel, se napaka DNS bere kot mrtva povezava in začne ponovno povezavo, ki ne more ničesar popraviti.

Nobena od dveh smeri napake se ne pojavi v izhodni kodi. Stražar, zgrajen na tem signalu, je met kovanca z urnikom cron.

Preglejte nekaj, kar živi za tunelom

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

Preglejte od znotraj, najcenejša kontrola najprej. Če vmesnik obstaja, tunel stoji; iskanje poti do znanega notranjega naslova pove, da bi promet vstopil vanjo; TCP sonda do gostitelja na drugi strani pove, da nekaj v resnici odgovori. Same zahteve echo zavajajo: veliko notranjih gostiteljev rado odgovori na TCP, a zavrže ICMP, zato stražar, zgrajen na pingu, nenehno znova povezuje tunel, ki ni nikoli prenehal delovati.

Držite sono časovno omejeno in ji dajte ločeno izhodno stanje. Sonda, ki visi trideset sekund, spremeni stražarja v zaznavalnik izpadov z vgrajeno zakasnitvijo.

Izberite med eno vrstico in zanko

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

Vnos cron je ena vrstica brez spomina, kar ustreza prenosniku, kjer dodatna povezava nič ne stane. Nadzorovana zanka vodi števec in ukrepa šele po več zgrešenih poskusih, kar preprečuje, da bi nestabilna povezava sprožila nevihto ponovnih povezav. V vsakem primeru jo zaženite pod nadzornikom, da preživi sesutje in piše v dnevnik. Izberite glede na to, ali je odvečna povezava pomembna, ne glede na to, katera različica je krajš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 zanka šteje zaporedne napake, ne deleža v oknu. Okno potrebuje uro in spomin vzorcev, in večina napak v ročno napisanih stražarjih živi prav v tej aritmetiki.

Preklop je druga odločitev

Menjava strežnika se razlikuje od ponovne povezave. Najprej pretrgajte staro povezavo, ker bo drug odjemalec, ki se začne, medtem ko prvi še drži naslov, trčil. Štejte zaporedne napake pred preklopom, omejite poskuse in po dvigu nove povezave znova preglejte, namesto da bi zaupali izhodnemu stanju ukaza connect. Napačna konfiguracija ne bi smela krožiti skozi vsak strežnik v zanki.

Ne pregledujte lastnega javnega naslova strežnika VPN iz notranjosti polnega tunela. Ta kontrola je odvisna od stvari, ki jo preizkuša, in poroča o uspehu, ko poti, ki bi jo morala potrditi, že ni več.

Zabeležite, katera sonda je tekla, kaj je vrnila in kateri ukrep je sledil. Ta zapis spremeni skrivnostno ponovno povezavo v dogodek, ki ga je mogoče diagnosticirati.