Pingový hlídač nerozliší rozbitý tunel od zdravého

Ping na internet dokazuje méně, než se zdá. Sledujte tunel zevnitř, počítejte selhání před zásahem a přepnutí berte jako samostatné rozhodnutí.

Tři podmínky rozhodují o tom, zda hlídač pomáhá, nebo škodí: co dokáže sonda rozlišit, kolik po sobě jdoucích selhání ospravedlní zásah a zda je zásahem opětovné připojení, nebo přepnutí. Řádek cronu, který pinguje veřejnou adresu, na žádnou z nich dobře neodpovídá. Připojuje znovu tunely, které jsou v pořádku, a nechává být tunely, které jsou rozbité, a obojí dělá bez záznamu. Návrh, který stojí za to zachovat, tyto tři volby činí výslovnými.

Sonda je část, která určuje všechno ostatní.

Co ping na internet skutečně dokazuje

Ping na veřejný resolver ukazuje, že místní internetová cesta je živá. Nedokazuje, že tunel přenáší provoz, a u profilu plného tunelu putuje samotný ping tunelem, takže zdravá odpověď a rozbitý tunel mohou existovat současně, zatímco klient stále předává pakety. Pokud profil posílá hledání jmen tunelem, selhání DNS se čte jako mrtvé spojení a spustí opětovné připojení, které nemůže nic opravit.

Ani jeden ze dvou směrů chyby se v návratovém kódu neobjeví. Hlídač postavený na tomto signálu je hod mincí s plánem cronu.

Sledujte něco, co žije za tunelem

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

Sledujte zevnitř, nejdřív nejlevnější kontrola. Existence rozhraní říká, že tunel je nahoře; hledání trasy k známé vnitřní adrese říká, že by do ní provoz vešel; TCP sonda na hostitele na druhé straně říká, že něco skutečně odpovídá. Samotné požadavky echo klamou: mnoho vnitřních hostitelů ochotně odpovídá na TCP, ale zahazuje ICMP, takže hlídač postavený na pingu stále znovu připojuje tunel, který nikdy nepřestal fungovat.

Držte sondu časově omezenou a dejte jí vlastní návratový stav. Sonda, která visí třicet sekund, mění hlídače v detektor výpadků s vestavěným zpožděním.

Vyberte mezi jedním řádkem a smyčkou

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

Záznam v cronu je jediný řádek bez paměti, což se hodí k notebooku, kde další připojení nic nestojí. Hlídaná smyčka drží počítadlo a jedná teprve poté, co několik kontrol selže, což brání nestabilnímu spojení vyvolat bouři opětovných připojení. V obou případech ji spouštějte pod správcem, aby přežila pád a psala do žurnálu. Vybírejte podle toho, zda záleží na falešném připojení, ne podle toho, která verze je kratší.

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 smyčka počítá po sobě jdoucí selhání, ne podíl za okno. Okno potřebuje hodiny a paměť vzorků a většina chyb v ručně psaných hlídačích žije právě v této aritmetice.

Přepnutí je jiné rozhodnutí

Přepínání serverů se liší od opětovného připojení. Nejprve roztrhněte staré spojení, protože druhý klient, který začne, dokud první stále drží adresu, se srazí. Počítejte po sobě jdoucí selhání před přepnutím, omezit pokusy a po nahození nového spojení sondu zopakujte, místo abyste věřili návratovému kódu příkazu connect. Špatná konfigurace by neměla rotovat skrz každý server ve smyčce.

Nesledujte vlastní veřejnou adresu VPN serveru zevnitř plného tunelu. Ta kontrola závisí na věci, kterou testuje, a hlásí úspěch, zatímco cesta, kterou měla ověřit, je pryč.

Zaznamenejte, která sonda běžela, co vrátila a jaká akce následovala. Ten záznam mění záhadné připojení v diagnostikovatelnou událost.

Související články