Ping sargas neskiria sugedusio tunelio nuo sveiko

Trys sąlygos lemia, ar sargas padeda, ar kenkia: ką gali atskirti patikra, kiek iš eilės nesėkmių pateisina veiksmą ir ar veiksmas yra pakartotinis prisijungimas, ar perjungimas. Cron eilutė, kuri pinga viešą adresą, nė į vieną jų gerai neatsako. Ji iš naujo prijungia tunelius, kurie yra tvarkingi, ir palieka sugedusius, ir daro abu be jokio įrašo. Dizainas, kurį verta išsaugoti, šiuos tris pasirinkimus padaro aiškius.

Patikra yra dalis, kuri lemia visa kita.

Ką iš tikrųjų įrodo ping į internetą

Ping į viešą resolverį rodo, kad vietinis interneto kelias gyvas. Tai neįrodo, kad tunelis perduoda srautą, o viso tunelio profilyje pats ping keliauja per tunelį, todėl sveikas atsakymas ir sugedęs tunelis gali egzistuoti kartu, kol klientas dar persiunčia paketus. Jei profilis siunčia vardų paieškas per tunelį, DNS gedimas skaitomas kaip negyva jungtis ir pradeda pakartotinį prisijungimą, kuris nieko negali pataisyti.

Nė viena iš dviejų klaidos krypčių nepasirodo išėjimo kode. Sargas, pastatytas ant šio signalo, yra monetos metimas su cron grafiku.

Tikrinkite tai, kas gyvena už tunelio

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

Tikrinkite iš vidaus, pigiausia patikra pirmiausia. Ar sąsaja egzistuoja, sako, kad tunelis pakeltas; maršruto paieška į žinomą vidinį adresą sako, kad srautas į jį pateks; TCP patikra į hostą kitoje pusėje sako, kad kažkas tikrai atsako. Vien echo užklausos klaidina: daug vidinių hostų mielai atsako į TCP, bet numeta ICMP, todėl ping pagrindu veikiantis sargas nuolat iš naujo prijungia tunelį, kuris niekada nenustojo veikti.

Laikykite patikrą apribotą laike ir duokite jai atskirą išėjimo būseną. Patikra, kuri kabo trisdešimt sekundžių, paverčia sargą pertraukimų detektoriumi su įtaisytu vėlavimu.

Rinkitės tarp vienos eilutės ir ciklo

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

Cron įrašas yra viena eilutė be atminties, kas tinka nešiojamajam kompiuteriui, kur papildomas prisijungimas nieko nekainuoja. Prižiūrimas ciklas laiko skaitiklį ir veikia tik po kelių praleidimų, kas neleidžia nepastoviai linijai sukelti prisijungimų audros. Bet kuriuo atveju paleiskite jį po priežiūros programa, kad jis išgyventų strigtį ir rašytų į žurnalą. Rinkitės pagal tai, ar nereikalingas prisijungimas svarbus, o ne pagal tai, kuri versija trumpesnė.

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

Tas ciklas skaičiuoja iš eilės nesėkmes, o ne dalį per langą. Langas reikalauja laikrodžio ir pavyzdžių atminties, ir dauguma rankomis rašytų sargų klaidų gyvena būtent toje aritmetikoje.

Perjungimas yra kitas sprendimas

Serverių keitimas skiriasi nuo pakartotinio prisijungimo. Pirmiausia nutraukite seną jungtį, nes antras klientas, pradėjęs, kol pirmasis dar laiko adresą, susidurs. Skaičiuokite iš eilės nesėkmes prieš keičiant, apribokite bandymus ir patikrinkite iš naujo, kai nauja jungtis bus pakelta, o ne pasitikėkite komandos connect išėjimo būsena. Neteisinga konfigūracija neturėtų suktis per kiekvieną serverį cikle.

Netikrinkite paties VPN serverio viešo adreso iš viso tunelio vidaus. Ta patikra priklauso nuo to, ką ji testuoja, ir praneša apie sėkmę, kai kelio, kurį turėjo patvirtinti, jau nėra.

Užrašykite, kuri patikra veikė, ką ji grąžino ir koks veiksmas sekė. Tas įrašas paslaptingą prisijungimą paverčia diagnozuojamu įvykiu.