A ping-őr nem tudja megkülönböztetni a törött alagutat az egészségestől

Az internetre küldött ping kevesebbet bizonyít, mint látszik. Vizsgálja az alagutat belülről, számolja a hibákat a cselekvés előtt, és kezelje a szerverváltást külön döntésként.

Három feltétel dönti el, hogy egy őr segít vagy árt: mit tud a vizsgálat megkülönböztetni, hány egymást követő hiba indokol cselekvést, és hogy a cselekvés újracsatlakozás vagy váltás-e. Egy cron-sor, amely nyilvános címre pingel, egyikre sem ad jó választ. Újracsatlakoztatja a rendben lévő alagutakat, és békén hagyja a törötteket, és mindkettőt feljegyzés nélkül teszi. A megtartásra érdemes terv ezt a három választást teszi egyértelművé.

A vizsgálat az a rész, amely minden mást eldönt.

Mit bizonyít valójában egy ping az internetre

Egy nyilvános feloldó pingelése azt mutatja, hogy a helyi internetútvonal él. Nem bizonyítja, hogy az alagút forgalmat visz, és teljes alagút profil esetén maga a ping is az alagúton keresztül halad, így egy egészséges válasz és egy törött alagút egyszerre is létezhet, miközben a kliens még továbbítja a csomagokat. Ha a profil a névkereséseket az alagúton küldi, a DNS-hiba halott kapcsolatként olvasódik, és olyan újracsatlakozást indít, amely semmit sem tud helyrehozni.

A hiba egyik iránya sem jelenik meg a kilépési kódban. Egy erre a jelre épített őr pénzfeldobás cron-ütemezéssel.

Vizsgáljon valamit, ami az alagút mögött él

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

Belülről vizsgáljon, a legolcsóbb ellenőrzés először. Ha létezik a felület, az alagút fent van; egy ismert belső címre mutató útvonalkeresés azt jelzi, hogy a forgalom belépne; egy TCP-vizsgálat a túloldali gazdagépre azt jelzi, hogy valami valóban válaszol. Csak az echo-kérések tévesztenek meg: sok belső gazdagép szívesen válaszol TCP-re, de eldobja az ICMP-t, ezért a pingre épített őr folyton újracsatlakoztat egy alagutat, amely soha nem hagyta abba a működést.

Tartsa a vizsgálatot időben korlátozottan, és adjon neki külön kilépési állapotot. Egy harminc másodpercig lógó vizsgálat késleltetéssel beépített kiesésérzékelővé teszi az őrt.

Válasszon egy sor és egy hurok között

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

A cron-bejegyzés egyetlen sor memória nélkül, ami olyan laptopon megfelelő, ahol egy plusz újracsatlakozás semmibe sem kerül. Egy felügyelt hurok számlálót tart, és csak több kihagyás után cselekszik, ami megakadályozza, hogy egy ingadozó kapcsolat újracsatlakozási vihart indítson. Mindkét esetben felügyelő alatt futtassa, hogy túléljen egy összeomlást, és írjon a naplóba. Aszerint válasszon, hogy számít-e egy fölösleges újracsatlakozás, nem aszerint, melyik változat rövidebb.

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

Ez a hurok egymást követő hibákat számol, nem egy ablakra eső hányadot. Egy ablakhoz óra és minták emlékezete kell, és a kézzel írt őrök hibáinak többsége ebben az aritmetikában él.

A váltás más döntés

A szerverváltás különbözik az újracsatlakozástól. Először szakítsa le a régi kapcsolatot, mert egy második kliens, amely akkor indul, amikor az első még tartja a címet, ütközni fog. Számolja az egymást követő hibákat a váltás előtt, korlátozza a próbákat, és az új kapcsolat felállása után ismét vizsgáljon, ahelyett hogy a connect parancs kilépési állapotában bízna. Egy hibás konfigurációnak nem szabad hurokban végigfutnia minden szerveren.

Ne vizsgálja a VPN-szerver saját nyilvános címét egy teljes alagút belsejéből. Ez az ellenőrzés attól függ, amit tesztel, és sikert jelent, miközben az az útvonal, amelyet igazolnia kellett volna, már nincs meg.

Jegyezze fel, melyik vizsgálat futott, mit adott vissza, és milyen művelet követte. Ez a feljegyzés diagnosztizálható eseménnyé tesz egy rejtélyes újracsatlakozást.

Kapcsolódó cikkek